This is the exact way I've proposed somewhere. I'll reference the issue later if I haven't closed it already. It only makes sense to be here... Otherwise we should just scrap the whole idea and promote users of sf2 to make their own types for these use cases and use the current entity transformers which is easy to do (as fosuserbundle bundle does I believe). ORMs should be responsible to allow for this functionality. I think the whole new type is kind of pointless as proposed in #1951.

I'm on my iPad, but have a look at fosuserbundle and see how they use the existing entities transformer.

+1 for this way.

@jstout24 we don't use the existing transformer. We provide a transformer using our UserManagerInterface and allowing to enter a username and getting a user. It is not a generic implementation at all, but one that work whatever backend you sue for the FOSUserBundle storage.

@stof ah that's right. It's been a while since I looked. I saw someone use it before :p.. Maybe it was lichess or something else. :p

yeah, this data transformer has originally been added in FOSUserBundle to be used in lichess as ornicar implemented it there first and thought it may be useful to provide it in the bundle directly.

A quick question.. would using "text" as a widget render a when it should be hidden? or would this end up rendering the hidden field and a text field for autocomplete functionality?

@jstout24
It would be:

• using the widget to render the identifier field.
• optionally, using the property option would add an additionnal field to show this property.

So, it would possible to have

• an identifier text field alone
• an identifier hidden field alone
• an identifier hidden field + a property text field (the autocomplete case)

Some pending questions after Stof's remarks:

• A easier name for EntityToArrayTransformer. I proposed EntityToIdentifierAndPropertyTransformer.
• The query_builder has to be replaced by a generic loader. I proposed to add a generic find function for the EntityLoaderInterface because we should find the entity in the restricted query and not on the whole list (so not a find on EntityManager).

One more case that should be possible from my experience:

• no or empty identifier hidden field + property text field (autocomplete case when javascript not available)

Then we need to specify a custom transformer for property text field -> entity (maybe using a closure).

Example: I've got a text field for a person which is filled with autocomplete in the format:
firstName lastName [ID]. This way the form could also work when javascript is disabled by letting the user name the person. The problem with transformers is that I can raise a validation error with TransformationFailedException but this is just a generic error. I would like to specify a real error message like "Your input is ambiguos" (when the user left out the ID and there are several people with the same name). This can only be achieved with a Listener. Like I did in https://github.com/Tobion/Tropaion/blob/master/src/Tobion/TropaionBundle/Form/EventListener/TransformAthletesListener.php

I would appreciate if such functionality would be possible with the Entity form type.

@Tobion Yes. Thanks for this comment.

As the transformer convert an entity to an array of identifier and property, I think I could add a case to retrieve an entity from the property if it's defined and if the identifier did not give a valid entity.

Something like:

  $entity = $this->em->find($this->class, $key);
  if ($this->property && !$entity) {
      $entity = $em->getRepository($class)->findOneBy(array($property => $value));
  }

Does it match your case?

Regards,

Well, not exactly. The property does not need to be a database column. So you can not simply search for it. I would rather suggest to allow a closure in this case. And we still need to find a way to add real errors.

@Tobion Ok I understand, it's a step further. In a first time, I would like to have at least the basic way. Maybe it could be the subject of an other PR in the future.

@RapotOR killer!

@bschussek can you give your mind on this PR ?

Also note that this PR will conflict with the refactoring done in #3156

I think that the idea behind this PR is good. This should be added as a generic option to ChoiceType though.

After the refactoring done in #3156 this should be quite easy to implement, without even the need of extra value transformers. The tricky question, as already discussed above, is how to exactly design the field options to be versatile yet understandable.

@bschussek: Can you confirm that this PR is better than the approach in #1951?

@fabpot: Not yet, both of them are on my todo list.

@bschussek ping

@RapotOR Please rebase your branch. It conflicts with master because of the move of the tests

@stof difficult for me at this moment.
if i am not wrong, it is not a basic rebase since the ChoiceType has been refactored in #3156.

Btw, there are different concurrent ideas, it could be great to have an official guideline for that.
Concurrent ideas are:

• Having a separated type: PR [2.2] [Form] Added form type "entity_identifier" (#1946) #1951
• Using the widget option in EntityType: current PR
• Using the widget option in ChoiceType: same idea than current PR but generally applied to ChoiceType (mentioned by @bschussek).

@bschussek @fabpot please give your mind about the preferred way

New discussion on this in #6602. Can this be closed?

Closed in favor of #6602.

I don't mean to be rude, but the last comment is from April 2013 and Symfony 2.5 has not been supported for ages. You should seriously consider upgrading your project to a supported version.

You can use a custom query to fetch the entities, see EntityType Field in the docs

Please consider using our support channels for this! Thank you!

https://symfony.com/support