Form Options & Variables: Dream Team

Hey Selman555!

You're totally right about that. But, can you tell me what you're trying to accomplish? We show getBlockPrefix() being used in this chapter. Are you trying to customize the actual name="" attribute on your form fields?

Cheers!

Hi,
No the name attribute can stay the same as far as I'm concerned.

In my case I have simple array of Setting entities fetched from database. It feels natural to just iterate through them and create a form for each of the entities and pass all the forms to the view. But the id="" and for="" attributes are prefixed with the FQDN of Setting::class. This results in duplicate ID's.

I use CSRF-tokens as well in every form so I can validate the source of the post. The tokens are invalid from the second form down, probably because the second form is submitting data for the first form (I'm not sure).

The sad part is that in a FormType, the `getBlockPrefixes()` method is called first, so I can't change the prefix in the configuration methods.

Does this make sense?
I have posted a question on stackoverflow: https://stackoverflow.com/q...
I'm still trying to figure out how I can implement the answer I got.

Greetings from Belgium

Hey Selman555!

Ah, yes, now I understand much better :). One important question is: do you need each as an actual individual form, or one big form? I think you want individual forms, so actually, that answer on Stackoverflow won't help (and it looks complex).

And you're right - the CSRF token is based on the form name, so it's being re-used and (I'm pretty sure) cleared/reset in the session after the first form submits. Fortunately, we can use a lower-level method to create the form, which gives you more control. In a controller:

use Symfony\Component\Form\FormFactoryInterface;

public function editSettings(FormFactoryInterface $formFactory)
{
    // $setting here represents one Setting object - you'll probably have some sort of loop, but you get the idea
    $form = $formFactory->createNamedBuilder('settings_'.$setting->getId(), SettingFormType::class, $setting)->getForm();
}

This createNamedBuilder() is actually what the normal $this->createForm() code eventually calls... but when IT calls it, the first argument to createNamedBuilder() - which is the form NAME - is set to the block prefix. By using this lower-level method, you can create a unique name for each form.

I haven't tried this code, but I think it should solve everything. Or... get us closer ;).

Cheers!

Yo Daan!

1) Performance can be an issue with forms... but only once you have many (e.g. 50, 100 or more) fields in your form. Just check out your web debug toolbar's "Performance" tab if you'd like: you can see if a page is slowing down that has a form. So, it's definitely possible... but probably not an issue.

2) Yep, this is a really good question! So usually, the "thing" that you're selecting is a list that lives in a database somewhere. That means that - other than the fact that having 1000 options on your page is horrible UI (and slow to load) - the EntityType is the perfect solution. And the EntityType really gives you two things: (A) it renders as a select element with all of your entities as options and (B) [much more importantly] when the id of the selected entity is submitted (e.g. 5) the EntityType queries for this and converts it into that object (e.g. Genus) before setting it back on your object.

What we want is that second functionality (B) but with a field that renders as a hidden field. The setup would look like this:

i) Field renders as an `&ltinput type="hidden" value="5" />
ii) You build some jQuery magic auto-complete magic, completely independent of the form system (except that it should read the "5" as the default value, and when you select the a new option, it should override the value with the id of the newly selected option).
iii) When you submit the id, you would want the (B) functionality above to convert the id (e.g. 5) back into your entity.

Unfortunately, this type of "HiddenEntityId" field doesn't exist in Symfony (though it's been proposed). But, you can add a custom field pretty easily - here's a bundle that has one (you can use this or use it as inspiration): https://github.com/Glifery/EntityHiddenTypeBundle and here's another example: https://gist.github.com/bjo3rnf/4061232. We do use this here on KnpU, it's really handy.

Let me know if that makes sense!

Cheers!

Awesome answers! I had to look up EntityType, but now I understand it!
Thank you for this bundle of knowledge!

Hey Greg!

Thanks for the tip - we had a typo on our end. Chapter 8 had a typo - it should be better now: https://knpuniversity.com/s...

Cheers!

Hey Ryan,

You're always the best.
Thanks and I wait the doctrine manytomany ;)