In this video we are going to take our first look at Symfony's Form Component.
Symfony's Form is one of the most powerful pieces of the entire framework. It's useful in more ways than are immediately obvious, but it's incredibly important to understand the basics before moving on to the more complex ways it can be used.
The official documentation for the form is really good, and there plenty of Cookbook articles to expand on some of the more intricate parts of form usage. Be sure to check out the docs as your first point of reference if you find yourself getting stuck or frustrated.
Perhaps my biggest criticism of Symfony as a whole is that there are often too many ways to do any one thing.
Teaching relative newcomers to the framework how something can be done and them then saying:
"oh, I already knew how to do that but I do it like this instead..."
is quite frustrating. Neither of us are incorrect, but multiple paths to the same destination lead to confusion. Confusion leads to suffering. Suffering leads to the dark side.
And of course, the dark side is switching to Ruby on Rails. Hey, come back, I kid. I kid.
The flip side to this is that you are not restricted to doing things only one way. This is great as your knowledge and comfort level with using Symfony grows. There's a lot of flexibility in having this level of choice, but it does make your initial learning that extra bit harder.
For me, the light bulb moment with the Form (however you use it) was when I began to understand how the form works behind the scenes.
Conceptually this is quite simple.
We have a form, and we have our data.
The form can be created without any data on it (an empty form).
Or we can pass in some data to the form which will be mapped on to the form fields for us.
The first way is easy enough. We add in some form fields, and then when the form is passed into the view (think: rendered to our Twig template), we get a form rendered off for us ready for our user to add in whatever data we are requesting.
If this were a contact form for example, this might be the users name, email, and message.
It's unlikely you would want to render off a contact form with any of the fields pre-populated with data. It's equally unlikely that on submission you would want to re-display the form with the data they just submitted back on the form (i.e. their name, email, and message in the respective fields) which might cause them to accidentally resubmit the form a few times needlessly.
The second way is a little more complicated. We need to make sure the data being put into the form actually matches up with what is expected / allowed.
Typically this would be done by building our forms based on Doctrine entities. We would define our form type (think of this like a form blueprint, all our fields but no data) and then when we use that form type, we would pass in a matching data entity that would be mapped / put over the top of the form. So long as the data matches up with the given fields, when the form is displayed, the data will populate the fields properly.
This is the fundamental thing to understand.
Another way to think of this might be to remember back to when you were a kid. Let's say you got an Optimus Prime figure for Christmas. Your brother got the Megatron figure. When you open the box, your shiny new Optimus figure is sat inside a clear plastic mould. That mould is perfectly contoured to the shape of Optimus.
The mould is our form.
You remove Optimus and play with him. Woo, memories of childhood.
Your brother decides he has had enough of playing with Megatron and tries to smush him into your Optimus Prime mould. He won't fit.
Megatron is some bad form data. Symfony would be nice enough to display an error for us here. You might have had to resort to fisticuffs to stop your brother from destroying your pristine Optimus Prime toy box. Think of the eBay resale value!
Whilst there are a number of ways to use Symfony's form, in real world projects there is one way that is far more common than any other.
Most any sizable Symfony project will have a
src/YourBundle/Form/Type directory, stuffed full of all the available forms in your project.
The reason for this is that declaring forms this way allows them to be easily reused. This gets us out of a situation where we have a form for adding an entity, and perhaps a duplicate form for editing. Fewer lines of code mean fewer potential bugs.
This is also handy as you will immediately know where your forms live.
Plenty more documentation on that right here.
Unless I am missing a trick here, there is currently no easy to find documentation on adding in Bootstrap styling to our forms.
As we have already added Bootstrap's CSS to our base twig template we are good to go with this.
As of Symfony 2.6 we can make a simple change to our
app/config/config.yml file and get Bootstrap styling added to our form rendering for free.
twig: form: resources: ['bootstrap_3_layout.html.twig'] # resources: ['bootstrap_3_horizontal_layout.html.twig']
You can uncomment whichever you prefer.
This blog post is all the official documentation I can find on this.
If you have found this video helpful, please consider sharing. I really appreciate it.
|1||Beginners Guide to Symfony2.7||11:42|
|2||Symfony Routing and Controllers||11:40|
|3||Doctrine DBAL and ORM in Layman's Terms||10:28|
|4||Doctrine Tutorial - CRUD||09:24|
|5||Doctrine Relationships for Beginners||17:35|
|6||Symfony Forms for Beginners||15:01|
|7||Reusing and Putting Data Back In To Symfony Forms||11:24|
|8||An Introduction to Symfony Validation||09:00|
|9||Symfony Security for Beginners||13:27|
|10||Beginners Guide to Testing in Symfony||16:26|