Fixed the formatting of several lists to avoid problems when

javiereguiluz · javiereguiluz · commit 3b557a04bef3 · 2014-06-04T22:13:41.000+02:00
rendering the documentation on the website
diff --git a/components/http_kernel/introduction.rst b/components/http_kernel/introduction.rst
@@ -241,23 +241,23 @@ will be called after another event - ``kernel.controller`` - is dispatched.
     information is typically placed on the ``Request`` via the ``RouterListener``).
     This string is then transformed into a PHP callable by doing the following:
 
-    a) The ``AcmeDemoBundle:Default:index`` format of the ``_controller`` key
-    is changed to another string that contains the full class and method
-    name of the controller by following the convention used in Symfony2 - e.g.
-    ``Acme\DemoBundle\Controller\DefaultController::indexAction``. This transformation
-    is specific to the :class:`Symfony\\Bundle\\FrameworkBundle\\Controller\\ControllerResolver`
-    sub-class used by the Symfony2 Framework.
+    #. The ``AcmeDemoBundle:Default:index`` format of the ``_controller`` key
+       is changed to another string that contains the full class and method
+       name of the controller by following the convention used in Symfony2 - e.g.
+       ``Acme\DemoBundle\Controller\DefaultController::indexAction``. This transformation
+       is specific to the :class:`Symfony\\Bundle\\FrameworkBundle\\Controller\\ControllerResolver`
+       sub-class used by the Symfony2 Framework.
 
-    b) A new instance of your controller class is instantiated with no
-    constructor arguments.
+    #. A new instance of your controller class is instantiated with no
+       constructor arguments.
 
-    c) If the controller implements :class:`Symfony\\Component\\DependencyInjection\\ContainerAwareInterface`,
-    ``setContainer`` is called on the controller object and the container
-    is passed to it. This step is also specific to the  :class:`Symfony\\Bundle\\FrameworkBundle\\Controller\\ControllerResolver`
-    sub-class used by the Symfony2 Framework.
+    #. If the controller implements :class:`Symfony\\Component\\DependencyInjection\\ContainerAwareInterface`,
+       ``setContainer`` is called on the controller object and the container
+       is passed to it. This step is also specific to the  :class:`Symfony\\Bundle\\FrameworkBundle\\Controller\\ControllerResolver`
+       sub-class used by the Symfony2 Framework.
 
-    There are also a few other variations on the above process (e.g. if
-    you're registering your controllers as services).
+       There are also a few other variations on the above process (e.g. if
+       you're registering your controllers as services).
 
 .. _component-http-kernel-kernel-controller:
 
@@ -324,15 +324,15 @@ of arguments that should be passed when executing that callable.
     It then iterates over each of these arguments and uses the following tricks
     to determine which value should be passed for each argument:
 
-    a) If the ``Request`` attributes bag contains a key that matches the name
-    of the argument, that value is used. For example, if the first argument
-    to a controller is ``$slug``, and there is a ``slug`` key in the ``Request``
-    ``attributes`` bag, that value is used (and typically this value came
-    from the ``RouterListener``).
+    #. If the ``Request`` attributes bag contains a key that matches the name
+       of the argument, that value is used. For example, if the first argument
+       to a controller is ``$slug``, and there is a ``slug`` key in the ``Request``
+       ``attributes`` bag, that value is used (and typically this value came
+       from the ``RouterListener``).
 
-    b) If the argument in the controller is type-hinted with Symfony's
-    :class:`Symfony\\Component\\HttpFoundation\\Request` object, then the
-    ``Request`` is passed in as the value.
+    #. If the argument in the controller is type-hinted with Symfony's
+       :class:`Symfony\\Component\\HttpFoundation\\Request` object, then the
+       ``Request`` is passed in as the value.
 
 .. _component-http-kernel-calling-controller:
 
@@ -527,21 +527,21 @@ below for more details).
     and is called :class:`Symfony\\Component\\HttpKernel\\EventListener\\ExceptionListener`.
     The listener has several goals:
 
-    1) The thrown exception is converted into a
-    :class:`Symfony\\Component\\HttpKernel\\Exception\\FlattenException`
-    object, which contains all the information about the request, but which
-    can be printed and serialized.
-
-    2) If the original exception implements
-    :class:`Symfony\\Component\\HttpKernel\\Exception\\HttpExceptionInterface`,
-    then ``getStatusCode`` and ``getHeaders`` are called on the exception
-    and used to populate the headers and status code of the ``FlattenException``
-    object. The idea is that these are used in the next step when creating
-    the final response.
-
-    3) A controller is executed and passed the flattened exception. The exact
-    controller to render is passed as a constructor argument to this listener.
-    This controller will return the final ``Response`` for this error page.
+    #. The thrown exception is converted into a
+       :class:`Symfony\\Component\\HttpKernel\\Exception\\FlattenException`
+       object, which contains all the information about the request, but which
+       can be printed and serialized.
+
+    #. If the original exception implements
+       :class:`Symfony\\Component\\HttpKernel\\Exception\\HttpExceptionInterface`,
+       then ``getStatusCode`` and ``getHeaders`` are called on the exception
+       and used to populate the headers and status code of the ``FlattenException``
+       object. The idea is that these are used in the next step when creating
+       the final response.
+
+    #. A controller is executed and passed the flattened exception. The exact
+       controller to render is passed as a constructor argument to this listener.
+       This controller will return the final ``Response`` for this error page.
 
     **ExceptionListener in Security**
 
diff --git a/cookbook/form/data_transformers.rst b/cookbook/form/data_transformers.rst
@@ -189,21 +189,21 @@ types of underlying data.
 .. image:: /images/cookbook/form/DataTransformersTypes.png
    :align: center
 
-In any form, the 3 different types of data are:
+In any form, the three different types of data are:
 
-1) **Model data** - This is the data in the format used in your application
-(e.g. an ``Issue`` object). If you call ``Form::getData`` or ``Form::setData``,
-you're dealing with the "model" data.
+#. **Model data** - This is the data in the format used in your application
+   (e.g. an ``Issue`` object). If you call ``Form::getData`` or ``Form::setData``,
+   you're dealing with the "model" data.
 
-2) **Norm Data** - This is a normalized version of your data, and is commonly
-the same as your "model" data (though not in our example). It's not commonly
-used directly.
+#. **Norm Data** - This is a normalized version of your data, and is commonly
+   the same as your "model" data (though not in our example). It's not commonly
+   used directly.
 
-3) **View Data** - This is the format that's used to fill in the form fields
-themselves. It's also the format in which the user will submit the data. When
-you call ``Form::submit($data)``, the ``$data`` is in the "view" data format.
+#. **View Data** - This is the format that's used to fill in the form fields
+   themselves. It's also the format in which the user will submit the data. When
+   you call ``Form::submit($data)``, the ``$data`` is in the "view" data format.
 
-The 2 different types of transformers help convert to and from each of these
+The two different types of transformers help convert to and from each of these
 types of data:
 
 **Model transformers**:
diff --git a/cookbook/form/dynamic_form_modification.rst b/cookbook/form/dynamic_form_modification.rst
@@ -7,22 +7,22 @@ How to Dynamically Modify Forms Using Form Events
 Often times, a form can't be created statically. In this entry, you'll learn
 how to customize your form based on three common use-cases:
 
-1) :ref:`cookbook-form-events-underlying-data`
+#. :ref:`cookbook-form-events-underlying-data`
 
-Example: you have a "Product" form and need to modify/add/remove a field
-based on the data on the underlying Product being edited.
+   Example: you have a "Product" form and need to modify/add/remove a field
+    based on the data on the underlying Product being edited.
 
-2) :ref:`cookbook-form-events-user-data`
+#. :ref:`cookbook-form-events-user-data`
 
-Example: you create a "Friend Message" form and need to build a drop-down
-that contains only users that are friends with the *current* authenticated
-user.
+   Example: you create a "Friend Message" form and need to build a drop-down
+   that contains only users that are friends with the *current* authenticated
+   user.
 
-3) :ref:`cookbook-form-events-submitted-data`
+#. :ref:`cookbook-form-events-submitted-data`
 
-Example: on a registration form, you have a "country" field and a "state"
-field which should populate dynamically based on the value in the "country"
-field.
+   Example: on a registration form, you have a "country" field and a "state"
+   field which should populate dynamically based on the value in the "country"
+   field.
 
 If you wish to learn more about the basics behind form events, you can
 take a look at the :doc:`Form Events </components/form/form_events>`
