@@ -255,9 +255,7 @@ the ``data_class`` option by adding the following to your form type class::
255
255
Rendering Forms
256
256
---------------
257
257
258
- Now that the form has been created, the next step is to render it. Instead of
259
- passing the entire form object to the template, use the ``createView() `` method
260
- to build another object with the visual representation of the form::
258
+ Now that the form has been created, the next step is to render it::
261
259
262
260
// src/Controller/TaskController.php
263
261
namespace App\Controller;
@@ -281,10 +279,14 @@ to build another object with the visual representation of the form::
281
279
}
282
280
}
283
281
282
+ In versions prior to Symfony 5.3, controllers used the method
283
+ ``$this->render('...', ['form' => $form->createView()]) `` to render the form.
284
+ The ``renderForm() `` method abstracts this logic and it also sets the 422 HTTP
285
+ status code in the response automatically when the submitted form is not valid.
286
+
284
287
.. versionadded :: 5.3
285
288
286
- The ``renderForm `` method was introduced in Symfony 5.3, allowing to
287
- return 422 HTTP status code if an invalid form is submitted.
289
+ The ``renderForm() `` method was introduced in Symfony 5.3.
288
290
289
291
Then, use some :ref: `form helper functions <reference-form-twig-functions >` to
290
292
render the form contents:
@@ -438,12 +440,6 @@ possible paths:
438
440
that prevents the user from being able to hit the "Refresh" button of
439
441
their browser and re-post the data.
440
442
441
- .. caution ::
442
-
443
- The ``createView() `` method should be called *after * ``handleRequest() `` is
444
- called. Otherwise, when using :doc: `form events </form/events >`, changes done
445
- in the ``*_SUBMIT `` events won't be applied to the view (like validation errors).
446
-
447
443
.. seealso ::
448
444
449
445
If you need more control over exactly when your form is submitted or which
0 commit comments