As I said in the inline comment, using the label is wrong. Labels are not identifiers. You cannot require uniqueness on them.

@stof : good catches, I'll try to update the PR accordingly.

About "values or labels" discussion, clearly both of them are valid use cases to me, but as the original "entity_id" idea could easily be done with the current implementation, I went for labels. The opposite isn't true, for example in an autocompletion field, you'd have to maintain a hidden field containing ids, while you'd show an non-mapped field where autocompletion is applied and populated with labels.

What about an option then? view_data for example, that could be set to label or value.

Edit : see genemu/GenemuFormBundle#122, for the autocompletion use case.

@bamarni as I said previously, labels are not valid. You cannot identify the choice by its label. You can have several choices with the same label (or even all of them).

Actually my implementation is not the way to go, thoses 2 methods I've introduced don't make sense because here with the text widget there is no such things as "labels" anymore, we're only dealing with "values".

So the option I'm talking about would only replace values by labels in the ChoiceList object, and it wouldn't add any data transformer or whatsoever, its behavior would remain the same, of course as you said, when enabling this, uniqueness would obviously be required on labels.

A simple use case to legitimate this option, let's say I have a User entity. In my backoffice, I want to let admins search for a user by its id through a text input. On the other end, on the frontoffice, I have a simple user mailing page, users can enter a message, and then populate a text field with a recipient (user login).

Digging into the code again I've found a much better approach, there is a createValue() extension point in choice lists, what do you think?

@bamarni Will it works with composite PKs?

ping @bschussek

@Koc : yes and no, it can work with this kind of entity but as the property option can only be set to a single column, in that situation there has to be another unique column you can rely on, usually the label should do the trick I guess.

@bschussek : what do you think of this implementation? should I continue or you have something else in mind?

ping @webmozart

Is this feature still being worked on?

Not since a while, I was still waiting for @webmozart feedback about the approach. Basically it does a bit more than the suggested "entity_id" form type would, in the sense that it also allow to use any other entity property (of course it has to be unique). I can continue this PR if we decide this approach is the way to go.

Hi @bamarni, thank you again for working on this issue! Sorry you had to wait so long for my feedback.

The ChoiceList implementation changed quite a bit in Symfony 2.7. Do you think you could rebase your work on the 2.8 branch?

@webmozart : thanks for the feedback, I've implemented the first part for the moment (on the Form component), cf. #15053