[2.2] [Form] Added form type "entity_identifier" (#1946) #1951

Gregwar · 2011-08-12T17:06:57Z

(You can have a look at the issue #1946)

The "entity_id" type allow you to do things such:

        $builder->add('city', 'entity_id', array(
            'query_builder' => function($repository, $id) {
                return $repository->createQueryBuilder('c')
                    ->where('c.id = :id AND c.available = 1')
                    ->setParameter('id', $id);
            },  
            'class' => 'Gregwar\TestBundle\Entity\City',
            'required' => false,
            'hidden' => true
        ));

So, with some JS logics and UI, you can fill the field directly using the entity id.

If you pass hidden => false, a text input will be rendered, which can allow an user to provide the id manually.

If you don't pass a query_builder closure, ->find() will be used.

ericclemmons · 2011-08-12T19:27:03Z

Have you tried using a FormExtension to add a prototype option, where you can define hidden, text, integer, etc.? I ask since entity performs most of this work & translation already: the issue is more along the lines of how to render it.

Gregwar · 2011-08-12T19:43:38Z

No, the issue is not about the way it's rendered.

As mentionned in the issue #1946, the problem with the entity type is that it will always fetch all the records from the database and then act like a choice type.

What if you want your user to choose among thousands of cities ?

And, even if you don't have many entries in your database, do you think that's normal to fetch everything in PHP and then look if the id is part of the results ?

stof · 2011-08-15T18:12:13Z

src/Symfony/Bridge/Doctrine/Form/DataTransformer/OneEntityToIdTransformer.php

+        $meta = $this->em->getClassMetadata($this->class);
+
+        if (!$meta->getReflectionClass()->isInstance($data))
+            throw new TransformationFailedException('Invalid data, must be an instance of '.$this->class);


you need to add the curly braces here.

marcw · 2011-08-16T09:25:19Z

src/Symfony/Bridge/Doctrine/Form/DataTransformer/OneEntityToIdTransformer.php

+        }
+
+        $identifierField = $meta->getSingleIdentifierFieldName();
+        $id = $meta->getReflectionProperty($identifierField)->getValue($data);


Using Reflection here is actually a problem because we lose the ability of the Proxy to load the missing properties of the entity.

Should I use "Form\Util\PropertyPath" to get the id value then ?

I sent you a PR on your Bundle which is inspired of the original EntityToIdTransformer.
btw, I don't think it's a good idea to use the Form PropertyPath.

Gregwar · 2011-08-16T20:06:33Z

I added the support of "property" options which you can use to search entries using an alternative field instead of the real database id.

Example of use

Imagine you want to implement a simple "message" entity which users can send to others, you want to add a recipient field in which they can type the login of the other users, you simply do:

$builder->add('recipient', 'entity_id', array(
    'class' => 'Acme\DemoBundle\Entity\User',
    'property' => 'login',
    'hidden' => false
));

And entity_id will do all the job !

You can of course put autocompletion and everything you want for your UI, and still override the query_builder to fetch the entity, but using the property instead of the id to search it.

stof · 2011-08-20T13:33:10Z

src/Symfony/Bridge/Doctrine/Form/DataTransformer/OneEntityToIdTransformer.php

+        }
+
+        if (!$result) {
+            throw new TransformationFailedException('Can not find entity');


TransformationFailedException are turned into errors by the Form class. This is the way to add errors in transformers (see the doc of the interface)

Gregwar · 2011-08-21T17:41:42Z

I just updated my FormBundle repo if you want to use entity_id :
https://github.com/Gregwar/FormBundle

stof · 2011-08-21T17:53:56Z

src/Symfony/Bridge/Doctrine/Form/Type/EntityIdType.php

+        $options = array_replace($defaultOptions, $options);
+
+        if (null === $options['class']) {
+            throw new \RunTimeException('You must provide a class option for the entity_id field');


it should be a FormException instead

phidah · 2011-08-22T16:43:17Z

+1

winzou · 2011-08-23T05:48:30Z

Massive +1 to this PR.

Shouldn't you rename it to entity_single or something like that ? Entity_id is obsolete since you added the property option.

Gregwar · 2011-08-23T07:25:30Z

@winzou, that's right, I'm still not sure about the name...

Note that If you read "entity identifer", you understand well what the field does in any case; it is an information that identifies an entity. Maybe entity_identifier ?

The problem with entity_single is that the entity type can also be used to choose a single entity so it would be a little confusing

Any feedbacks about that ?

phidah · 2011-08-23T07:34:15Z

entity_identifier sounds fine to me.

j · 2011-09-05T17:37:15Z

So I'm needing something similar to this. My current use case uses elastic search and javascript autopopulate on an input field. Upon clicking, I of course set that id to the hidden field, but I also need to populate a select options with relational data to what was clicked... So I get the argument error on both the hidden type as well as the choice type.

I'd rather not have to render another hidden type for an onchange event of the relational choice type... so perhaps having the option to specify what kind of "empty" field you would like to render?

And a name like "empty_entity" makes more sense to me

Gregwar · 2011-09-06T08:19:26Z

@jstout24, I think that would imply moving the "text" and "hidden" form types services from FrameworkBundle to the DoctrineBundle, and I'm not sure that's a good idea because of code coupling concerns.

And I'm not sure I understand why do you want this to be empty ?

j · 2011-09-06T18:24:26Z

@Gregwar, I don't quite understand. I just mean that most use cases would need just a hidden field, but what about if you're using javascript to populate a select.

ie:

There are Users > Zipcode (100,000+ records) > SexOffenders (about 20 per zip)

Users need a location in a zipcode database (very large, as you were saying.. an autocomplete box passing ID to a hidden entity type would suffice for this.)

But let's say after they enter their zipcode, I want to populate a regular ... The select should automatically bind to entity SexOffender.. whereas using this FormType, I'd have to also write an onchange event to the SexOffender select to input that id to the hidden field. Maybe it doesn't need to be within this type unless it was renamed to "empty_entity" or something..... This current implementation is for only <input type="hidden".... /> However, if 'choices' => array() could ensure that no data is selected: $builder->add('sexOffenders', 'entity', array( 'class' => 'Acme\DemoBundle\Entity\SexOffender', 'choices' => array() )); Or just create an empty option for the EntityType: $builder->add('sexOffenders', 'entity', array( 'class' => 'Acme\DemoBundle\Entity\SexOffender', 'empty' => true )); Also, another thing I wanted to do was have a hidden DateType but was limited by the documentation (I'm not sure if it's possible) Thoughts?

j · 2011-09-11T18:50:26Z

What's the status of this PR?

stof · 2012-05-15T21:28:13Z

@jstout24 it would need to be done the same way than the current entity type: an abstract class extended for each Doctrine project to change the name (we cannot register 2 types with the same name), the deps injected in it (once the ORM registry and once the ODM registry) and eventually some other method needing to be changed (to support query builders for instance)

j · 2012-05-16T05:21:25Z

@stof yup, I like the sound of that! :p

Sent from my iPhone

On May 15, 2012, at 2:28 PM, Christophe Coevoet
reply@reply.github.com
wrote:

@jstout24 it would need to be done the same way than the current entity type: an abstract class extended for each Doctrine project to change the name (we cannot register 2 types with the same name), the deps injected in it (once the ORM registry and once the ODM registry) and eventually some other method needing to be changed (to support query builders for instance)

Reply to this email directly or view it on GitHub:
#1951 (comment)

webmozart · 2012-05-16T17:29:34Z

I'd prefer putting this into ChoiceType. Basically it is the same as ChoiceType but with a different widget and lazy loading.

j · 2012-05-16T18:06:08Z

@bschussek yeah it's a choice (kind of) if one was to have an input with some sort of javascript autocomplete. It's not much of a ChoiceType if it's not used in this manner.

For example, from a recent problem I ran into, I had a Form with a collection... I added javascript to reposition the items on the DOM and do an ajax post. After the first post, all is great. If I reposition without reloading the form and rebinding the data, I get crazy weird results. I'm assuming this is from the 0-indexed behaviour the ArrayCollection? This may be a problem with the collection type.

I used to do it like so:

<input type="hidden" name="children[0][id]" value="9" />
<input type="hidden" name="children[0][position]" value="1" />
<input type="hidden" name="children[1][id]" value="3" />
<input type="hidden" name="children[1][position]" value="2" />

I could open up an issue on the above if it makes sense to.

Anyway, back to this topic.

This is why I was in favor of being able to associate a hidden field to a model and make it easier for other ORMs/etc to adapt to.

If it's always going to be up to the method of setting data of the form to associate models, and the hidden entity type is always going to be for "choice" functionality ChoiceType makes more sense imo.

thalionath · 2012-05-25T08:33:16Z

+1 to this request

jnonon · 2012-06-27T19:18:17Z

Any updates?

stof · 2012-06-27T21:48:11Z

As you could see in the title and the milestone, this has been scheduled for 2.2 as 2.1 is now frozen as it is in beta

jnonon · 2012-06-27T22:00:08Z

I did not noticed. Thanks for replying.

lmcd · 2012-10-05T05:25:59Z

Any idea when this will land?

lmcd · 2012-10-06T05:32:46Z

src/Symfony/Bridge/Doctrine/Form/DataTransformer/OneEntityToIdTransformer.php

+            return null;
+        }
+        if (!$this->unitOfWork->isInIdentityMap($data)) {
+            throw new FormException('Entities passed to the choice field must be managed');


Does the entity have to be managed if a property is provided? In my case, I'm providing an unserialized entity from the session that's not managed by the entity manager. It has an ID, so there's no reason for it not to work.

Can we move this check after if ($this->property) {}?

mvrhov · 2012-11-02T18:57:14Z

I'm also wondering when this one will land

ahilles107 · 2012-11-04T22:44:42Z

src/Symfony/Bridge/Doctrine/Form/DataTransformer/OneEntityToIdTransformer.php

+            // Call the closure with the repository and the id
+            $qb = $qb($repository, $data);
+
+            try {


Why not use getOneOrNullResult?

Gregwar · 2012-11-22T06:57:39Z

Yes, this PR is going too far IMO, more than one year and very much comments... @fabpot, can you please do something about it?

come · 2012-11-22T08:31:35Z

+1 to this request

mkleins · 2012-11-22T08:34:16Z

faster, stronger. I like this PR.

luxifer · 2012-11-22T08:44:01Z

+1 for ths PR

bamarni · 2012-11-23T14:21:01Z

Well this will probably not be merged as @bschussek stated he preferred having this done in entity type or maybe abstract it into choice type.

Baachi · 2012-11-29T11:20:53Z

src/Symfony/Bridge/Doctrine/Form/Type/EntityIdentifierType.php

+        ));
+    }
+
+    public function getDefaultOptions(array $options)


The method is deprecated.

You should have a look to https://github.com/Gregwar/FormBundle/blob/master/Type/EntityIdType.php#L40
The component is up to date there ! :)

apsylone · 2012-11-29T20:27:31Z

+1 for this PR ! What about it @fabpot, @stof ?!

nurikabe · 2012-12-04T18:29:42Z

+1

joericochuyt · 2012-12-07T13:17:32Z

+1

michaelperrin · 2013-01-07T09:54:19Z

This form type could avoid the need to create data transformers in some cases, making code easier to read & write.

+1 !

webmozart · 2013-01-07T13:35:21Z

Closed in favor of #6602.

[Form] Added the entity_id type (symfony#1946)

05a064a

stof reviewed Aug 15, 2011
View reviewed changes

[Form] Fixing coding standard problems (see PR symfony#1951)

662691a

marcw reviewed Aug 16, 2011
View reviewed changes

Grégoire Passault and others added 2 commits August 16, 2011 12:17

[Form] Changes the way the identifier is retrieved

4a62fc3

[Form] Added support of "property" on the "entity_id" type

6f11075

stof reviewed Aug 20, 2011
View reviewed changes

Added a RuntimeException when no class is provided

0802d83

stof reviewed Aug 21, 2011
View reviewed changes

[Form] Using FormException instead of RuntimeException for entity_id

295bd6d

[Form] Renamed field type name "entity_id" to "entity_identifier"

38713e2

webmozart mentioned this pull request Jul 23, 2012

[Form] two FormView instances of the same form type influence each other #4987

Closed

lmcd reviewed Oct 6, 2012
View reviewed changes

bamarni mentioned this pull request Oct 30, 2012

Lazy choice list (Autocompletion cities) genemu/GenemuFormBundle#122

Open

ahilles107 reviewed Nov 4, 2012
View reviewed changes

Burgov mentioned this pull request Nov 22, 2012

Extend the EntityIdentifierType if it ever gets pulled to symfony master SamsonIT/AutocompleteBundle#3

Open

Baachi reviewed Nov 29, 2012
View reviewed changes

webmozart mentioned this pull request Jan 7, 2013

[Form] Add option "widget" to ChoiceType #6602

Closed

webmozart closed this Jan 7, 2013

jakzal mentioned this pull request Dec 7, 2013

[2.3][Form] HiddenEntityType #8293

Closed

[2.2] [Form] Added form type "entity_identifier" (#1946) #1951

[2.2] [Form] Added form type "entity_identifier" (#1946) #1951

Conversation

Gregwar commented Aug 12, 2011

ericclemmons commented Aug 12, 2011

Gregwar commented Aug 12, 2011

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Gregwar commented Aug 16, 2011

Example of use

Choose a reason for hiding this comment

Gregwar commented Aug 21, 2011

Choose a reason for hiding this comment

phidah commented Aug 22, 2011

winzou commented Aug 23, 2011

Gregwar commented Aug 23, 2011

phidah commented Aug 23, 2011

j commented Sep 5, 2011

Gregwar commented Sep 6, 2011

j commented Sep 6, 2011

j commented Sep 11, 2011

stof commented May 15, 2012

j commented May 16, 2012

webmozart commented May 16, 2012

j commented May 16, 2012

thalionath commented May 25, 2012

jnonon commented Jun 27, 2012

stof commented Jun 27, 2012

jnonon commented Jun 27, 2012

lmcd commented Oct 5, 2012

Choose a reason for hiding this comment

mvrhov commented Nov 2, 2012

Choose a reason for hiding this comment

Gregwar commented Nov 22, 2012

come commented Nov 22, 2012

mkleins commented Nov 22, 2012

luxifer commented Nov 22, 2012

bamarni commented Nov 23, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apsylone commented Nov 29, 2012

nurikabe commented Dec 4, 2012

joericochuyt commented Dec 7, 2012

michaelperrin commented Jan 7, 2013

webmozart commented Jan 7, 2013