Forms

Forms are one of the most misused Symfony components due to its vast scope and
endless list of features. In this chapter we'll show you some of the best
practices so you can leverage forms but get work done quickly.

The Form component allows you to build forms right inside your controller
code. This is perfectly fine if you don't need to reuse the form somewhere else.
But for organization and reuse, we recommend that you define each
form in its own PHP class:

You can also register your form type as a service.
This is only needed if your form type requires some dependencies to be injected
by the container, otherwise it is unnecessary overhead and therefore not
recommended to do this for all form type classes.

Form classes should try to be agnostic to where they will be used. This
makes them easier to re-use later.

Best Practice

Best Practice

Add buttons in the templates, not in the form classes or the controllers.

The Symfony Form component allows you to add buttons as fields on your form.
This is a nice way to simplify the template that renders your form. But if you
add the buttons directly in your form class, this would effectively limit the
scope of that form:

This form may have been designed for creating posts, but if you wanted
to reuse it for editing posts, the button label would be wrong. Instead,
some developers configure form buttons in the controller:

This is also an important error, because you are mixing presentation markup
(labels, CSS classes, etc.) with pure PHP code. Separation of concerns is
always a good practice to follow, so put all the view-related things in the
view layer:

There are a lot of ways to render your form, ranging from rendering the entire
thing in one line to rendering each part of each field independently. The
best way depends on how much customization you need.

One of the simplest ways - which is especially useful during development -
is to render the form tags and use the form_widget() function to render
all of the fields:

If you need more control over how your fields are rendered, then you should
remove the form_widget(form) function and render your fields individually.
See How to Customize Form Rendering for more information on this and how you
can control how the form renders at a global level using form theming.

publicfunctionnewAction(Request$request){// build the form ...$form->handleRequest($request);if($form->isSubmitted()&&$form->isValid()){$em=$this->getDoctrine()->getManager();$em->persist($post);$em->flush();return$this->redirect($this->generateUrl('admin_post_show',array('id'=>$post->getId())));}// render the template}

There are really only two notable things here. First, we recommend that you
use a single action for both rendering the form and handling the form submit.
For example, you could have a newAction() that only renders the form
and a createAction() that only processes the form submit. Both those
actions will be almost identical. So it's much simpler to let newAction()
handle everything.

Second, is it required to call $form->isSubmitted() in the if statement
before calling isValid(). Calling isValid() with an unsubmitted form
is deprecated since version 3.2 and will throw an exception in 4.0.