Merge branch '2.4' into 2.5

book/doctrine.rst

@@ -413,12 +413,12 @@ doesn't replace your existing methods).
 
     With the ``doctrine:generate:entities`` command you can:
 
-        * generate getters and setters;
+    * generate getters and setters;
 
-        * generate repository classes configured with the
-            ``@ORM\Entity(repositoryClass="...")`` annotation;
+    * generate repository classes configured with the
+      ``@ORM\Entity(repositoryClass="...")`` annotation;
 
-        * generate the appropriate constructor for 1:n and n:m relations.
+    * generate the appropriate constructor for 1:n and n:m relations.
 
     The ``doctrine:generate:entities`` command saves a backup of the original
     ``Product.php`` named ``Product.php~``. In some cases, the presence of
@@ -631,7 +631,7 @@ Once you have your repository, you have access to all sorts of helpful methods::
 You can also take advantage of the useful ``findBy`` and ``findOneBy`` methods
 to easily fetch objects based on multiple conditions::
 
-    // query for one product matching be name and price
+    // query for one product matching by name and price
     $product = $repository->findOneBy(
         array('name' => 'foo', 'price' => 19.99)
     );

book/http_cache.rst

@@ -1034,7 +1034,7 @@ Cache Invalidation
 ------------------
 
     "There are only two hard things in Computer Science: cache invalidation
-    and naming things." --Phil Karlton
+    and naming things." -- Phil Karlton
 
 You should never need to invalidate cached data because invalidation is already
 taken into account natively in the HTTP cache models. If you use validation,

book/security.rst

@@ -854,8 +854,8 @@ if ``ip``, ``host`` or ``method`` are not specified for an entry, that ``access_
 will match any ``ip``, ``host`` or ``method``:
 
 +-----------------+-------------+-------------+------------+--------------------------------+-------------------------------------------------------------+
-| **URI**         | **IP**      | **HOST**    | **METHOD** | ``access_control``             | Why?                                                        |
-+-----------------+-------------+-------------+------------+--------------------------------+-------------------------------------------------------------+
+| URI             | IP          | HOST        | METHOD     | ``access_control``             | Why?                                                        |
++=================+=============+=============+============+================================+=============================================================+
 | ``/admin/user`` | 127.0.0.1   | example.com | GET        | rule #1 (``ROLE_USER_IP``)     | The URI matches ``path`` and the IP matches ``ip``.         |
 +-----------------+-------------+-------------+------------+--------------------------------+-------------------------------------------------------------+
 | ``/admin/user`` | 127.0.0.1   | symfony.com | GET        | rule #1 (``ROLE_USER_IP``)     | The ``path`` and ``ip`` still match. This would also match  |

book/templating.rst

@@ -75,19 +75,17 @@ to web designers and, in several ways, more powerful than PHP templates:
         </body>
     </html>
 
-Twig defines two types of special syntax:
+Twig defines three types of special syntax:
 
 * ``{{ ... }}``: "Says something": prints a variable or the result of an
   expression to the template;
 
 * ``{% ... %}``: "Does something": a **tag** that controls the logic of the
   template; it is used to execute statements such as for-loops for example.
 
-.. note::
-
-   There is a third syntax used for creating comments: ``{# this is a comment #}``.
-   This syntax can be used across multiple lines like the PHP-equivalent
-   ``/* comment */`` syntax.
+* ``{# ... #}``: "Comment something": it's the equivalent of the PHP
+  ``/* comment */`` syntax. It's used to add single or multi-line comments.
+  The content of the comments isn't included in the rendered pages.
 
 Twig also contains **filters**, which modify content before being rendered.
 The following makes the ``title`` variable all uppercase before rendering
@@ -394,14 +392,14 @@ lives in a specific location:
   template for a specific page. The three parts of the string, each separated
   by a colon (``:``), mean the following:
 
-    * ``AcmeBlogBundle``: (*bundle*) the template lives inside the
-      ``AcmeBlogBundle`` (e.g. ``src/Acme/BlogBundle``);
+  * ``AcmeBlogBundle``: (*bundle*) the template lives inside the
+    ``AcmeBlogBundle`` (e.g. ``src/Acme/BlogBundle``);
 
-    * ``Blog``: (*controller*) indicates that the template lives inside the
-      ``Blog`` subdirectory of ``Resources/views``;
+  * ``Blog``: (*controller*) indicates that the template lives inside the
+    ``Blog`` subdirectory of ``Resources/views``;
 
-    * ``index.html.twig``: (*template*) the actual name of the file is
-      ``index.html.twig``.
+  * ``index.html.twig``: (*template*) the actual name of the file is
+    ``index.html.twig``.
 
   Assuming that the ``AcmeBlogBundle`` lives at ``src/Acme/BlogBundle``, the
   final path to the layout would be ``src/Acme/BlogBundle/Resources/views/Blog/index.html.twig``.

components/config/introduction.rst

@@ -5,12 +5,9 @@
 The Config Component
 ====================
 
-Introduction
-------------
-
-The Config component provides several classes to help you find, load, combine,
-autofill and validate configuration values of any kind, whatever their source
-may be (YAML, XML, INI files, or for instance a database).
+    The Config component provides several classes to help you find, load,
+    combine, autofill and validate configuration values of any kind, whatever
+    their source may be (YAML, XML, INI files, or for instance a database).
 
 .. caution::
 

components/css_selector.rst

@@ -55,7 +55,7 @@ This gives the following output:
 
 .. code-block:: text
 
-    descendant-or-self::div[contains(concat(' ',normalize-space(@class), ' '), ' item ')]/h4/a
+    descendant-or-self::div[@class and contains(concat(' ',normalize-space(@class), ' '), ' item ')]/h4/a
 
 You can use this expression with, for instance, :phpclass:`DOMXPath` or
 :phpclass:`SimpleXMLElement` to find elements in a document.
@@ -76,17 +76,15 @@ web-browser.
 
 * link-state selectors: ``:link``, ``:visited``, ``:target``
 * selectors based on user action: ``:hover``, ``:focus``, ``:active``
-* UI-state selectors: ``:enabled``, ``:disabled``, ``:indeterminate``
-  (however, ``:checked`` and ``:unchecked`` are available)
+* UI-state selectors: ``:invalid``, ``:indeterminate`` (however, ``:enabled``, 
+  ``:disabled``, ``:checked`` and ``:unchecked`` are available)
 
 Pseudo-elements (``:before``, ``:after``, ``:first-line``,
 ``:first-letter``) are not supported because they select portions of text
 rather than elements.
 
 Several pseudo-classes are not yet supported:
 
-* ``:lang(language)``
-* ``root``
 * ``*:first-of-type``, ``*:last-of-type``, ``*:nth-of-type``,
   ``*:nth-last-of-type``, ``*:only-of-type``. (These work with an element
   name (e.g. ``li:first-of-type``) but not with ``*``.

components/event_dispatcher/introduction.rst

@@ -5,6 +5,10 @@
 The EventDispatcher Component
 =============================
 
+    The EventDispatcher component provides tools that allow your application
+    components to communicate with each other by dispatching events and listening
+    to them.
+
 Introduction
 ------------
 

components/form/form_events.rst

@@ -62,8 +62,8 @@ The ``FormEvents::PRE_SET_DATA`` event is dispatched at the beginning of the
 :ref:`Form Events Information Table<component-form-event-table>`
 
 +-----------------+-----------+
-| **Data type**   | **Value** |
-+-----------------+-----------+
+|   Data type     | Value     |
++=================+===========+
 | Model data      | ``null``  |
 +-----------------+-----------+
 | Normalized data | ``null``  |
@@ -99,8 +99,8 @@ the form.
 :ref:`Form Events Information Table<component-form-event-table>`
 
 +-----------------+------------------------------------------------------+
-| **Data type**   | **Value**                                            |
-+-----------------+------------------------------------------------------+
+| Data type       | Value                                                |
++=================+======================================================+
 | Model data      | Model data injected into ``setData()``               |
 +-----------------+------------------------------------------------------+
 | Normalized data | Model data transformed using a model transformer     |
@@ -110,6 +110,9 @@ the form.
 
 .. sidebar:: ``FormEvents::POST_SET_DATA`` in the Form component
 
+    .. versionadded:: 2.4
+        The data collector extension was introduced in Symfony 2.4.
+
     The :class:`Symfony\\Component\\Form\\Extension\\DataCollector\\EventListener\\DataCollectorListener`
     class is subscribed to listen to the ``FormEvents::POST_SET_DATA`` event
     in order to collect information about the forms from the denormalized
@@ -141,8 +144,8 @@ It can be used to:
 :ref:`Form Events Information Table<component-form-event-table>`
 
 +-----------------+------------------------------------------+
-| **Data type**   | **Value**                                |
-+-----------------+------------------------------------------+
+| Data type       | Value                                    |
++=================+==========================================+
 | Model data      | Same as in ``FormEvents::POST_SET_DATA`` |
 +-----------------+------------------------------------------+
 | Normalized data | Same as in ``FormEvents::POST_SET_DATA`` |
@@ -171,8 +174,8 @@ It can be used to change data from the normalized representation of the data.
 :ref:`Form Events Information Table<component-form-event-table>`
 
 +-----------------+-------------------------------------------------------------------------------------+
-| **Data type**   | **Value**                                                                           |
-+-----------------+-------------------------------------------------------------------------------------+
+| Data type       | Value                                                                               |
++=================+=====================================================================================+
 | Model data      | Same as in ``FormEvents::POST_SET_DATA``                                            |
 +-----------------+-------------------------------------------------------------------------------------+
 | Normalized data | Data from the request reverse-transformed from the request using a view transformer |
@@ -203,8 +206,8 @@ It can be used to fetch data after denormalization.
 :ref:`Form Events Information Table<component-form-event-table>`
 
 +-----------------+---------------------------------------------------------------+
-| **Data type**   | **Value**                                                     |
-+-----------------+---------------------------------------------------------------+
+| Data type       | Value                                                         |
++=================+===============================================================+
 | Model data      | Normalized data reverse-transformed using a model transformer |
 +-----------------+---------------------------------------------------------------+
 | Normalized data | Same as in ``FormEvents::POST_SUBMIT``                        |
@@ -218,6 +221,9 @@ It can be used to fetch data after denormalization.
 
 .. sidebar:: ``FormEvents::POST_SUBMIT`` in the Form component
 
+    .. versionadded:: 2.4
+        The data collector extension was introduced in Symfony 2.4.
+
     The :class:`Symfony\\Component\\Form\\Extension\\DataCollector\\EventListener\\DataCollectorListener`
     subscribes to the ``FormEvents::POST_SUBMIT`` event in order to collect
     information about the forms.
@@ -242,19 +248,19 @@ processed.
 
 .. _component-form-event-table:
 
-+--------------------+-------------------------------+------------------+
-| **Name**           | ``FormEvents`` **Constant**   | **Event's data** |
-+--------------------+-------------------------------+------------------+
-| form.pre_set_data  | ``FormEvents::PRE_SET_DATA``  | Model data       |
-+--------------------+-------------------------------+------------------+
-| form.post_set_data | ``FormEvents::POST_SET_DATA`` | Model data       |
-+--------------------+-------------------------------+------------------+
-| form.pre_bind      | ``FormEvents::PRE_SUBMIT``    | Request data     |
-+--------------------+-------------------------------+------------------+
-| form.bind          | ``FormEvents::SUBMIT``        | Normalized data  |
-+--------------------+-------------------------------+------------------+
-| form.post_bind     | ``FormEvents::POST_SUBMIT``   | View data        |
-+--------------------+-------------------------------+------------------+
++------------------------+-------------------------------+------------------+
+| Name                   | ``FormEvents`` Constant       | Event's data     |
++========================+===============================+==================+
+| ``form.pre_set_data``  | ``FormEvents::PRE_SET_DATA``  | Model data       |
++------------------------+-------------------------------+------------------+
+| ``form.post_set_data`` | ``FormEvents::POST_SET_DATA`` | Model data       |
++------------------------+-------------------------------+------------------+
+| ``form.pre_bind``      | ``FormEvents::PRE_SUBMIT``    | Request data     |
++------------------------+-------------------------------+------------------+
+| ``form.bind``          | ``FormEvents::SUBMIT``        | Normalized data  |
++------------------------+-------------------------------+------------------+
+| ``form.post_bind``     | ``FormEvents::POST_SUBMIT``   | View data        |
++------------------------+-------------------------------+------------------+
 
 .. versionadded:: 2.3
 

components/http_foundation/session_configuration.rst

@@ -37,7 +37,7 @@ activate these in the same way as it does for custom handlers.
 
 Symfony2 provides drivers for the following native save handler as an example:
 
-  * :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\NativeFileSessionHandler`
+* :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\NativeFileSessionHandler`
 
 Example usage::
 
@@ -71,11 +71,11 @@ various points in the session workflow.
 Symfony2 HttpFoundation provides some by default and these can easily serve as
 examples if you wish to write your own.
 
-  * :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\PdoSessionHandler`
-  * :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\MemcacheSessionHandler`
-  * :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\MemcachedSessionHandler`
-  * :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\MongoDbSessionHandler`
-  * :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\NullSessionHandler`
+* :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\PdoSessionHandler`
+* :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\MemcacheSessionHandler`
+* :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\MemcachedSessionHandler`
+* :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\MongoDbSessionHandler`
+* :class:`Symfony\\Component\\HttpFoundation\\Session\\Storage\\Handler\\NullSessionHandler`
 
 Example usage::