Join Jon Peck for an in-depth discussion in this video Displaying and debugging a form, part of Learning Symfony2 for PHP.
- Let's switch over to a browser to take a closer look at what's going on behind the scenes on a form. Let's go back to publication/new and we see a familiar form. However, let's look deeper. I'm using Google Chrome on a Mac, so I'm going to press shift-command-c to enter the inspect mode. On Windows, it's shift-control-c. Hover over the name and click, and go back up to the form. There's a couple things going on here: For one, the form name is Lynda magazine bundle publication, as well as the div ID.
That's the same form ID that was specified by getname in the publication type class. There is also a hidden input with an ID with the name of the form, __token. The value on your end is going to be a bit different than what I'm seeing. This is a cross-site request forgery token, which is generated automatically for you by default. It can optionally be customized. Very handy. Close the inspect window by clicking the X in the upper right hand corner. Remember Symfony's debug bar from earlier? Well, it's still here and it's got some debugging information for us.
The clipboard with what looks like a paper form has a number next to it. Click on it now. This will provide a debugging perspective into the form describing the model, submitted data, past options, and more. Click back to go back to the form, and let's submit a value. For the name of the publication, specify gravel gatherer, and click create. The publication is created, but let's check the debug form by clicking the icon again. Odd, the form wasn't submitted. Well, actually, that's technically accurate because it's redirecting upon completion.
So, go up, and click view last 10. See that post? Click the token next to it. Ah, that's a lot better. The request post parameters contain the gravel gatherer as we'd expect. Up on the top, the gear shows the HTTP status along with the controller name, the action name, and the route - something to keep in mind when debugging. Let's go back to the IDE to take a closer look at how the form is rendered. Over in resources, open up views, publication, and new.html.twig.
The form is rendered with just, well, form(form). That's it. Wait, really? Alright, let's take a look at the action. Open publication, controller, and navigate to create action. So in the return value, form is set to form, create view. The create view method within the form object creates a special form view object that the template can use to render the form. The result is actually rendered by a form helper using the syntax that we just saw, form(form).
However, many designers want a bit more control than that, and that's where form templates come in. For example, the form can be started, errors displayed, maybe in a div with a different class, then the row with the name element as displayed, and then the form is closed out. Even more granularity is possible, down to the widget with form theming. Okay, so we've got a sense of how a form is built and displayed, but what about adding validators for input?
- Installing Symfony
- Creating a bundle from the console
- Customizing and generating database tables
- Generating controllers
- Creating, editing, and debugging entities
- Displaying and debugging a form
- Rendering content with templates
Skill Level Intermediate
Q: When trying to access the application, I receive an error stating "This script is only accessible from localhost." How can I get around this restriction?
A: The development front controller and configuration scripts are protected by default to only allow access from the localhost. Refer to the video titled “Exploring the Symfony layout” to see how to disable this security.