We use cookies on this site to enhance your user experience. By clicking "OK, I Agree" or using our site, you consent to the use of cookies unless you have disabled them. View our cookie policy to learn more.
OK, I AGREE
TRACK
Symfony 4 >
COURSE
Symfony 4 Forms: Build, Render & Conquer!
Buy Access to Course

EntityType: Custom Query

Keep on Learning!

If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.

Start your All-Access Pass
Buy just this tutorial for $12.00
Previous Chapter

Next Chapter
Edit on Github

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Right click and "Inspect Element". Look at the value of each option: it's the id of that user in the database. So, when we choose an author, this is the value that will be submitted to the server: this number. Just remember that.

Time to author another award-winning article:

Pluto: I didn't want to be a Planet Anyways

Set the publish date to today at any time, select an author and... create! Yes! The author is [email protected] and it is published.

This is way more amazing than it might look at first! Sure, the EntityType is cool because it makes it easy to create a drop-down that's populated from the database. Blah, blah, blah. That's fine. But the truly amazing part of EntityType is its data transformer. It's the fact that, when we submit a number to the server - like 17 - it queries the database and transforms that into a User object. That's important because the form system will eventually call setAuthor(). And this method requires a User object as an argument - not the number 17. The data transformer is the magic that makes that happen.

Creating a Custom Query

We can use this new knowledge to our advantage! Go back to the create form. What if we don't want to show all of the users in this drop-down? Or, what if we want to control their order. How can we do that?

Normally, when you use the EntityType, you don't need to pass the choices option. Remember, if you look at ChoiceType, the choices option is how you specify which, ah, choices you want to show in the drop-down. But EntityType queries for the choices and basically sets this option for us.

To control that query, there's an option called query_builder. Or, you can do what I do: be less fancy and simply override the choices option entirely. Yep, you basically say:

Hey EntityType! Thanks... but I can handle querying for the choices myself. But, have a super day.

Injecting Dependencies

To do this, we need to execute a query from inside of our form class. And to do that, we need the UserRepository. But... great news! Form types are services! So we can use our favorite pattern: dependency injection.

Create an __construct() method with an UserRepository argument. I'll hit alt+enter, and select "Initialize Fields" to create that property and set it. Down below, pass choices set to $this->userRepository and I'll call a new method ->findAllEmailAlphabetical().

52 lines src/Form/ArticleFormType.php
... lines 1 - 14
class ArticleFormType extends AbstractType
{
private $userRepository;
public function __construct(UserRepository $userRepository)
{
$this->userRepository = $userRepository;
}
... line 23
public function buildForm(FormBuilderInterface $builder, array $options)
{
$builder
... lines 27 - 33
->add('author', EntityType::class, [
... lines 35 - 39
'choices' => $this->userRepository->findAllEmailAlphabetical(),
])
... line 42
}
... lines 44 - 50
}

Copy that name, go to src/Repository/, open UserRepository, and create that method. Use the query builder: return $this->createQueryBuilder('u') and then ->orderBy('u.email', 'ASC'). Finish with ->getQuery() and ->execute().

Above the method, we know that this will return an array of User objects. So, let's advertise that!

63 lines src/Repository/UserRepository.php
... lines 1 - 14
class UserRepository extends ServiceEntityRepository
{
... lines 17 - 21
/**
* @return User[]
*/
public function findAllEmailAlphabetical()
{
return $this->createQueryBuilder('u')
->orderBy('u.email', 'ASC')
->getQuery()
->execute()
;
}
... lines 33 - 61
}

I love it! This makes our ArticleFormType class happy. I think we should try it! Refresh! Cool! The admin users are first, then the others.

So... is EntityType Still Needed?

But... wait. Now that we're manually setting the choices option... do we even need to use EntityType anymore? Couldn't we switch to ChoiceType instead?

Actually... no! There is one super critical thing that EntityType is still giving us: data transformation. When we submit the form, we still need the submitted id to be transformed back into the correct User object. So, even though we're querying for the options manually, it is still doing this very important job for us. Remember: the true power of a field type is this data transformation ability.

Next: let's add some form validation! It might work a little differently than you expect.

Leave a comment!

  • 2019-07-16 weaverryan

    Yo halifaxious !

    Sorry for my slow reply on this one! I might (or might not) have something that would help. Basically, instead of using the query_builder option, it's total legal to query (however you want) for the final array of AbstractStoragePlaceProxy objects (sorry if I've got the entity wrong) that you want in the drop-down and pass that as the choices option. That gives you full control over how you query for the entities, but you still get the nice things where it correctly renders the select tag with the ids and hydrates whatever is chosen back into an object.

    To actually query for the entities you need, I would add a __construct() to your form class and autowire whatever repository you want (it looks like maybe the LocationDetailViewRepository might be the most useful (or you could autowire the EntityManagerInterface). Then, use that below in buildForm to query for the entities you need and pass to the choices option. No query_builder option needed.

    Let me know if that helps!

    Cheers!

  • 2019-07-09 halifaxious

    Is there a way to setup EntityType so that I can query one class of entity but return a different class?

    I have Location chooser based on a complex set of inherited entities (Site->Room->Sublocation are all the same parent class). If I query for a location list using these entities, getting the 'choice_label' values adds up to a ridiculous number of queries since each choice object calls a method that does another query. So I created a read-only view in my db along with an associate entity called `LocationDetailView` which has all the properties for a choice in one row. Terrific! Except that now I have to transform my `LocationDetailView` object into a `Location` object when it gets submitted. And so far as I can see, that means that I can't use an EntityType because the query_builder needs the class property to equal `LocationDetailView` while the form itself needs the class property to equal `Location`.

    Working code with stupid number of queries (between 2 and 4 per entity depending on subtype):


        public function configureOptions(OptionsResolver $resolver)
        {
              $resolver->setDefaults(array(
                  'class' => AbstractStoragePlaceProxy::class,
                  'query_builder' => function(EntityRepository $er) {
                        $qb = $er->createQueryBuilder('l');
                        $qb
                            ->leftJoin(LocationDetailView::class, 'v', Join::WITH, 'l.id = v.id')
                            ->orderBy('v.site')
                            ->addOrderBy('v.sortnum')
                            ->addOrderBy('v.sublocation');


                      if(!$this->authorizationChecker->isGranted('ROLE_ROOT')){
                            $userEntity = $this->tokenStorage->getToken()->getUser()->getUserEntity();
                            $rer = $this->em->getRepository(Room::class);
                            $rids = $rer->getMyRoomIds($userEntity, DelegateInterface::FULLACCESS);
                            $qb
              ->where($qb->expr()->in('v.rid', ':rids'))
                                ->setParameter('rids', $rids);
        }
                      return $qb;
                },
                'choice_label' => function($location){
                      return $location->getPath();
                },
                'group_by' => function($val, $key, $index){
                      $place = $val->getPlace();
                      $site = $place instanceof SubLocation ? $place->getRoom()->getSite() : $place->getSite();
                      return $site->getSiteAlias();
                }
      ));
        }

    Code that displays but won't submit due to wrong entity type:


    public function configureOptions(OptionsResolver $resolver)
       {


          $resolver->setDefaults(array(
          'class' => LocationDetailView::class,
          'query_builder' => function(EntityRepository $er) {
            $qb = $er->createQueryBuilder('v');
                    $qb
             ->orderBy('v.site')
             ->addOrderBy('v.sortnum')
             ->addOrderBy('v.sublocation');


                 if(!$this->authorizationChecker->isGranted('ROLE_ROOT')){
           $userEntity = $this->tokenStorage->getToken()->getUser()->getUserEntity();
           $rer = $this->em->getRepository(Room::class);
           $rids = $rer->getMyRoomIds($userEntity, DelegateInterface::FULLACCESS);
           $qb
             ->where($qb->expr()->in('v.rid', ':rids'))
             ->setParameter('rids', $rids);
          }
          return $qb;
            },
            'choice_label' => function(LocationDetailView $location){
          return trim(join('/',[$location->getRnum(),$location->getSublocation()]), '/');
            },
            'group_by' => function(LocationDetailView $location, $key, $index){
          return $location->getSite();
            }
          ));
       }
  • 2019-06-11 Diego Aguiar

    Hey Ionut Stoican

    A quick and easy way would be to handle both forms in the same controller's action. It's a bit ugly but you would save some troubles because of validations. If you split your submit actions into different routes then it would be somehow hard to print the form errors on the same page, probably would be better to handle it with some javascript code.

    Cheers!

  • 2019-06-08 Ionut Stoican

    How would I go if I wanted for example to have a registration and a login form on the same page?

Edit on Github
Previous Chapter
Next Chapter