Merge branch '2.3' into 2.7

* 2.3:
  [#6278] small tweak
  [HttpFoundation] Fix typo for ParameterBag getters
  Updated third param true to UrlGeneratorInterface::ABSOLUTE_URl in text Generating Absolute URLs
  fix yaml syntax
  [#6255] some tweaks
  Rewrite EventDispatcher introduction
  Fixed code example
  some tweaks to the Doctrine registration article
  mention routing from the database

Conflicts:
	components/event_dispatcher/introduction.rst

Author: xabbuh

book/routing.rst

@@ -1553,7 +1553,7 @@ Generating Absolute URLs
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 By default, the router will generate relative URLs (e.g. ``/blog``). From
-a controller, simply pass ``true`` to the third argument of the ``generateUrl()``
+a controller, simply pass ``UrlGeneratorInterface::ABSOLUTE_URL`` to the third argument of the ``generateUrl()``
 method::
 
     use Symfony\Component\Routing\Generator\UrlGeneratorInterface;

components/event_dispatcher/introduction.rst

@@ -140,7 +140,7 @@ has some methods to filter the input values:
 :method:`Symfony\\Component\\HttpFoundation\\ParameterBag::filter`
     Filters the parameter by using the PHP :phpfunction:`filter_var` function.
 
-All getters takes up to three arguments: the first one is the parameter name
+All getters take up to three arguments: the first one is the parameter name
 and the second one is the default value to return if the parameter does not
 exist::
 

components/http_foundation/introduction.rst

@@ -122,12 +122,12 @@ The output will look like this:
 .. code-block:: text
 
     assetic:
-        debug:                %kernel.debug%
+        debug:                '%kernel.debug%'
         use_controller:
-            enabled:              %kernel.debug%
+            enabled:              '%kernel.debug%'
             profiler:             false
-        read_from:            %kernel.root_dir%/../web
-        write_to:             %assetic.read_from%
+        read_from:            '%kernel.root_dir%/../web'
+        write_to:             '%assetic.read_from%'
         java:                 /usr/bin/java
         node:                 /usr/local/bin/node
         node_paths:           []

cookbook/bundles/installation.rst

@@ -35,7 +35,7 @@ Your ``User`` entity will probably at least have the following fields:
 ``plainPassword``
     This field is *not* persisted: (notice no ``@ORM\Column`` above it). It
     temporarily stores the plain password from the registration form. This field
-    can be validated then used to populate the ``password`` field.
+    can be validated and is then used to populate the ``password`` field.
 
 With some validation added, your class may look something like this::
 
@@ -127,17 +127,18 @@ With some validation added, your class may look something like this::
 
         public function getSalt()
         {
-            // The bcrypt algorithm don't require a separate salt.
+            // The bcrypt algorithm doesn't require a separate salt.
             // You *may* need a real salt if you choose a different encoder.
             return null;
         }
 
         // other methods, including security methods like getRoles()
     }
 
-The ``UserInterface`` requires a few other methods and your ``security.yml`` file
-needs to be configured properly to work with the ``User`` entity. For a more full
-example, see the :ref:`Entity Provider <security-crete-user-entity>` article.
+The :class:`Symfony\\Component\\Security\\Core\\User\\UserInterface` requires
+a few other methods and your ``security.yml`` file needs to be configured
+properly to work with the ``User`` entity. For a more complete example, see
+the :ref:`Entity Provider <security-crete-user-entity>` article.
 
 .. _cookbook-registration-password-max:
 
@@ -186,7 +187,7 @@ Next, create the form for the ``User`` entity::
         public function configureOptions(OptionsResolver $resolver)
         {
             $resolver->setDefaults(array(
-                'data_class' => 'AppBundle\Entity\User'
+                'data_class' => 'AppBundle\Entity\User',
             ));
         }
 
@@ -201,7 +202,8 @@ There are just three fields: ``email``, ``username`` and ``plainPassword``
 
 .. tip::
 
-    To explore more things about the Form component, read :doc:`/book/forms`.
+    To explore more things about the Form component, read the
+    :doc:`chapter about forms </book/forms>` in the book.
 
 Handling the Form Submission
 ----------------------------
@@ -213,12 +215,11 @@ into the database::
     // src/AppBundle/Controller/RegistrationController.php
     namespace AppBundle\Controller;
 
-    use Symfony\Bundle\FrameworkBundle\Controller\Controller;
-
     use AppBundle\Form\UserType;
     use AppBundle\Entity\User;
-    use Symfony\Component\HttpFoundation\Request;
     use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
+    use Symfony\Bundle\FrameworkBundle\Controller\Controller;
+    use Symfony\Component\HttpFoundation\Request;
 
     class RegistrationController extends Controller
     {
@@ -245,7 +246,7 @@ into the database::
                 $em->persist($user);
                 $em->flush();
 
-                // ... do any other work - like send them an email, etc
+                // ... do any other work - like sending them an email, etc
                 // maybe set a "flash" success message for the user
 
                 return $this->redirectToRoute('replace_with_some_route');
@@ -373,8 +374,8 @@ See :doc:`/cookbook/form/form_customization` for more details.
 Update your Database Schema
 ---------------------------
 
-If you've updated the User entity during this tutorial, you have to update your
-database schema using this command:
+If you've updated the ``User`` entity during this tutorial, you have to update
+your database schema using this command:
 
 .. code-block:: bash
 
@@ -406,9 +407,9 @@ return the ``email`` property::
         // ...
     }
 
-Next, just update the ``providers`` section of your ``security.yml`` so that Symfony
-knows to load your users via the ``email`` property on login. See
-:ref:`authenticating-someone-with-a-custom-entity-provider`.
+Next, just update the ``providers`` section of your ``security.yml`` file
+so that Symfony knows how to load your users via the ``email`` property on
+login. See :ref:`authenticating-someone-with-a-custom-entity-provider`.
 
 Adding a "accept terms" Checkbox
 --------------------------------

cookbook/doctrine/registration_form.rst

@@ -157,6 +157,7 @@
   * :doc:`/cookbook/routing/custom_route_loader`
   * :doc:`/cookbook/routing/redirect_trailing_slash`
   * :doc:`/cookbook/routing/extra_information`
+  * :doc:`/cookbook/routing/routing_from_database`
 
 * :doc:`Security Authentication (Identifying/Logging in the User) </cookbook/security/index>`
 

cookbook/map.rst.inc

@@ -12,3 +12,4 @@ Routing
     custom_route_loader
     redirect_trailing_slash
     extra_information
+    routing_from_database

cookbook/routing/index.rst

@@ -0,0 +1,41 @@
+.. index::
+   single: Routing; Extra Information
+
+Looking up Routes from a Database: Symfony CMF DynamicRouter
+============================================================
+
+The core Symfony Routing System is excellent at handling complex sets
+of routes. A highly optimized routing cache is dumped during
+deployments.
+
+However, when working with large amounts of data that each need a nice
+readable URL (e.g. for search engine optimization purposes), the routing
+can get slowed down. Additionally, if routes need to be edited by users,
+the route cache would need to be rebuilt frequently.
+
+For these cases, the ``DynamicRouter`` offers an alternative approach:
+
+* Routes are stored in a database;
+* There is a database index on the path field, the lookup scales to huge
+  numbers of different routes;
+* Writes only affect the index of the database, which is very efficient.
+
+When all routes are known during deploy time and the number is not too
+high, using a :doc:`custom route loader <custom_route_loader>` is the
+preferred way to add more routes. When working with just one type of
+objects, a slug parameter on the object and the ``@ParamConverter``
+annotation work fine (see FrameworkExtraBundle_) .
+
+The ``DynamicRouter`` is useful when you need ``Route`` objects with
+the full feature set of Symfony. Each route can define a specific
+controller so you can decouple the URL structure from your application
+logic.
+
+The DynamicRouter comes with built-in support for Doctrine ORM and Doctrine
+PHPCR-ODM but offers the ``ContentRepositoryInterface`` to write a custom
+loader, e.g. for another database type or a REST API or anything else.
+
+The DynamicRouter is explained in the `Symfony CMF documentation`_.
+
+.. _FrameworkExtraBundle: https://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/converters.html
+.. _`Symfony CMF documentation`: http://symfony.com/doc/master/cmf/book/routing.html

cookbook/routing/routing_from_database.rst

@@ -54,8 +54,8 @@ how you determine the desired locale from the request::
         public static function getSubscribedEvents()
         {
             return array(
-                // must be registered before the default Locale listener
-                KernelEvents::REQUEST => array(array('onKernelRequest', 17)),
+                // must be registered after the default Locale listener
+                KernelEvents::REQUEST => array(array('onKernelRequest', 15)),
             );
         }
     }