Merge pull request #1854 from richardmiller/removing_apostrophes

Removing a couple of incorrect apostrophes

Author: weaverryan

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!
+method knows to add the extra header. Have fun!

cookbook/form/dynamic_form_generation.rst

@@ -4,15 +4,15 @@
 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
     namespace Acme\DemoBundle\Form\Type;
 
     use Symfony\Component\Form\AbstractType;
     use Symfony\Component\Form\FormBuilder;
-    
+
     class ProductType extends AbstractType
     {
         public function buildForm(FormBuilder $builder, array $options)
@@ -29,28 +29,28 @@ 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 </book/forms>` 
+    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 </book/forms>`
     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 </components/event_dispatcher/introduction>`
-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`:
 
 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