diff --git a/cookbook/event_dispatcher/before_after_filters.rst b/cookbook/event_dispatcher/before_after_filters.rst index 258941125fc..4bebee88d79 100755 --- a/cookbook/event_dispatcher/before_after_filters.rst +++ b/cookbook/event_dispatcher/before_after_filters.rst @@ -5,7 +5,7 @@ How to setup before and after Filters ===================================== It is quite common in web application development to need some logic to be -executed just before or just after your controller actions acting as filters +executed just before or just after your controller actions acting as filters or hooks. In symfony1, this was achieved with the preExecute and postExecute methods. @@ -180,7 +180,7 @@ your listener to be called just before any controller is executed. With this configuration, your ``TokenListener`` ``onKernelController`` method will be executed on each request. If the controller that is about to be executed implements ``TokenAuthenticatedController``, token authentication is -applied. This let's us have a "before" filter on any controller that you +applied. This lets us have a "before" filter on any controller that you want. After filters with the ``kernel.response`` Event @@ -277,4 +277,4 @@ executed (``onKernelController``) and after every controller returns a response (``onKernelResponse``). By making specific controllers implement the ``TokenAuthenticatedController`` interface, our listener knows which controllers it should take action on. And by storing a value in the request's "attributes" bag, the ``onKernelResponse`` -method knows to add the extra header. Have fun! \ No newline at end of file +method knows to add the extra header. Have fun! diff --git a/cookbook/form/dynamic_form_generation.rst b/cookbook/form/dynamic_form_generation.rst index 79a07ab9d86..f6c69aeb6b8 100644 --- a/cookbook/form/dynamic_form_generation.rst +++ b/cookbook/form/dynamic_form_generation.rst @@ -4,7 +4,7 @@ How to Dynamically Generate Forms Using Form Events =================================================== -Before jumping right into dynamic form generation, let's have a quick review +Before jumping right into dynamic form generation, let's have a quick review of what a bare form class looks like:: // src/Acme/DemoBundle/Form/Type/ProductType.php @@ -12,7 +12,7 @@ of what a bare form class looks like:: use Symfony\Component\Form\AbstractType; use Symfony\Component\Form\FormBuilder; - + class ProductType extends AbstractType { public function buildForm(FormBuilder $builder, array $options) @@ -29,19 +29,19 @@ of what a bare form class looks like:: .. note:: - If this particular section of code isn't already familiar to you, you - probably need to take a step back and first review the :doc:`Forms chapter ` + If this particular section of code isn't already familiar to you, you + probably need to take a step back and first review the :doc:`Forms chapter ` before proceeding. Let's assume for a moment that this form utilizes an imaginary "Product" class -that has only two relevant properties ("name" and "price"). The form generated +that has only two relevant properties ("name" and "price"). The form generated from this class will look the exact same regardless of a new Product is being created or if an existing product is being edited (e.g. a product fetched from the database). -Suppose now, that you don't want the user to be able to change the ``name`` value +Suppose now, that you don't want the user to be able to change the ``name`` value once the object has been created. To do this, you can rely on Symfony's :doc:`Event Dispatcher ` -system to analyze the data on the object and modify the form based on the -Product object's data. In this entry, you'll learn how to add this level of +system to analyze the data on the object and modify the form based on the +Product object's data. In this entry, you'll learn how to add this level of flexibility to your forms. .. _`cookbook-forms-event-subscriber`: @@ -49,8 +49,8 @@ flexibility to your forms. Adding An Event Subscriber To A Form Class ------------------------------------------ -So, instead of directly adding that "name" widget via our ProductType form -class, let's delegate the responsibility of creating that particular field +So, instead of directly adding that "name" widget via our ProductType form +class, let's delegate the responsibility of creating that particular field to an Event Subscriber:: // src/Acme/DemoBundle/Form/Type/ProductType.php @@ -75,8 +75,8 @@ to an Event Subscriber:: } } -The event subscriber is passed the FormFactory object in its constructor so -that our new subscriber is capable of creating the form widget once it is +The event subscriber is passed the FormFactory object in its constructor so +that our new subscriber is capable of creating the form widget once it is notified of the dispatched event during form creation. .. _`cookbook-forms-inside-subscriber-class`: @@ -119,8 +119,8 @@ might look like the following:: // During form creation setData() is called with null as an argument // by the FormBuilder constructor. We're only concerned with when - // setData is called with an actual Entity object in it (whether new, - // or fetched with Doctrine). This if statement let's us skip right + // setData is called with an actual Entity object in it (whether new + // or fetched with Doctrine). This if statement lets us skip right // over the null condition. if (null === $data) { return; @@ -135,27 +135,27 @@ might look like the following:: .. caution:: - It is easy to misunderstand the purpose of the ``if (null === $data)`` segment - of this event subscriber. To fully understand its role, you might consider - also taking a look at the `Form class`_ and paying special attention to - where setData() is called at the end of the constructor, as well as the + It is easy to misunderstand the purpose of the ``if (null === $data)`` segment + of this event subscriber. To fully understand its role, you might consider + also taking a look at the `Form class`_ and paying special attention to + where setData() is called at the end of the constructor, as well as the setData() method itself. -The ``FormEvents::PRE_SET_DATA`` line actually resolves to the string ``form.pre_set_data``. +The ``FormEvents::PRE_SET_DATA`` line actually resolves to the string ``form.pre_set_data``. The `FormEvents class`_ serves an organizational purpose. It is a centralized location in which you can find all of the various form events available. -While this example could have used the ``form.set_data`` event or even the ``form.post_set_data`` -events just as effectively, by using ``form.pre_set_data`` we guarantee that -the data being retrieved from the ``Event`` object has in no way been modified -by any other subscribers or listeners. This is because ``form.pre_set_data`` -passes a `DataEvent`_ object instead of the `FilterDataEvent`_ object passed -by the ``form.set_data`` event. `DataEvent`_, unlike its child `FilterDataEvent`_, +While this example could have used the ``form.set_data`` event or even the ``form.post_set_data`` +events just as effectively, by using ``form.pre_set_data`` we guarantee that +the data being retrieved from the ``Event`` object has in no way been modified +by any other subscribers or listeners. This is because ``form.pre_set_data`` +passes a `DataEvent`_ object instead of the `FilterDataEvent`_ object passed +by the ``form.set_data`` event. `DataEvent`_, unlike its child `FilterDataEvent`_, lacks a setData() method. .. note:: - You may view the full list of form events via the `FormEvents class`_, + You may view the full list of form events via the `FormEvents class`_, found in the form bundle. .. _`DataEvent`: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Event/DataEvent.php