symfony
diff --git a/‎book/doctrine.rst‎
Lines changed: 4 additions & 4 deletions b/‎book/doctrine.rst‎
Lines changed: 4 additions & 4 deletions
diff --git a/‎book/forms.rst‎
Lines changed: 11 additions & 6 deletions b/‎book/forms.rst‎
Lines changed: 11 additions & 6 deletions
diff --git a/‎book/templating.rst‎
Lines changed: 3 additions & 3 deletions b/‎book/templating.rst‎
Lines changed: 3 additions & 3 deletions
diff --git a/‎contributing/code/patches.rst‎
Lines changed: 1 addition & 2 deletions b/‎contributing/code/patches.rst‎
Lines changed: 1 addition & 2 deletions
diff --git a/‎cookbook/assetic/asset_management.rst‎
Lines changed: 2 additions & 2 deletions b/‎cookbook/assetic/asset_management.rst‎
Lines changed: 2 additions & 2 deletions
diff --git a/‎cookbook/form/dynamic_form_modification.rst‎
Lines changed: 8 additions & 6 deletions b/‎cookbook/form/dynamic_form_modification.rst‎
Lines changed: 8 additions & 6 deletions
diff --git a/‎cookbook/form/form_customization.rst‎
Lines changed: 31 additions & 21 deletions b/‎cookbook/form/form_customization.rst‎
Lines changed: 31 additions & 21 deletions
diff --git a/‎cookbook/security/entity_provider.rst‎
Lines changed: 8 additions & 28 deletions b/‎cookbook/security/entity_provider.rst‎
Lines changed: 8 additions & 28 deletions
diff --git a/‎create_framework/dependency-injection.rst‎ renamed to ‎create_framework/dependency_injection.rst‎
Lines changed: 0 additions & 5 deletions b/‎create_framework/dependency-injection.rst‎ renamed to ‎create_framework/dependency_injection.rst‎
Lines changed: 0 additions & 5 deletions
@@ -953,8 +953,8 @@ To relate the ``Category`` and ``Product`` entities, start by creating a
                 products:
                     targetEntity: Product
                     mappedBy: category
-            # don't forget to init the collection in the __construct() method
-            # of the entity
+        # Don't forget to initialize the collection in
+        # the __construct() method of the entity
 
     .. code-block:: xml
 
@@ -1096,7 +1096,7 @@ table, and ``product.category_id`` column, and new foreign key:
 
 .. note::
 
-    This task should only be really used during development. For a more robust
+    This command should only be used during development. For a more robust
     method of systematically updating your production database, read about
     `migrations`_.
 
@@ -1187,7 +1187,7 @@ You can also query in the other direction::
         // ...
     }
 
-In this case, the same things occurs: you first query out for a single ``Category``
+In this case, the same things occur: you first query out for a single ``Category``
 object, and then Doctrine makes a second query to retrieve the related ``Product``
 objects, but only once/if you ask for them (i.e. when you call ``->getProducts()``).
 The ``$products`` variable is an array of all ``Product`` objects that relate
 
@@ -223,8 +223,8 @@ Handling Form Submissions
 
 The second job of a form is to translate user-submitted data back to the
 properties of an object. To make this happen, the submitted data from the
-user must be written into the form. Add the following functionality to your
-controller::
+user must be written into the Form object. Add the following functionality to
+your controller::
 
     // ...
     use Symfony\Component\HttpFoundation\Request;
@@ -694,9 +694,14 @@ the documentation for each type.
     The most common option is the ``required`` option, which can be applied to
     any field. By default, the ``required`` option is set to ``true``, meaning
     that HTML5-ready browsers will apply client-side validation if the field
-    is left blank. If you don't want this behavior, either set the ``required``
-    option on your field to ``false`` or
-    :ref:`disable HTML5 validation <book-forms-html5-validation-disable>`.
+    is left blank. If you don't want this behavior, either
+    :ref:`disable HTML5 validation <book-forms-html5-validation-disable>`
+    or set the ``required`` option on your field to ``false``::
+    
+        ->add('dueDate', 'date', array(
+            'widget' => 'single_text',
+            'required' => false
+        ))
 
     Also note that setting the ``required`` option to ``true`` will **not**
     result in server-side validation to be applied. In other words, if a
@@ -935,7 +940,7 @@ specify it:
 
 Some field types have additional rendering options that can be passed
 to the widget. These options are documented with each type, but one common
-options is ``attr``, which allows you to modify attributes on the form element.
+option is ``attr``, which allows you to modify attributes on the form element.
 The following would add the ``task_field`` class to the rendered input text
 field:
 
 
@@ -201,7 +201,7 @@ First, build a base layout file:<
3261
/div>
         <!DOCTYPE html>
         <html>
             <head>
-                <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+                <meta charset="UTF-8">
                 <title>{% block title %}Test Application{% endblock %}</title>
             </head>
             <body>
@@ -226,7 +226,7 @@ First, build a base layout file:
         <!DOCTYPE html>
         <html>
             <head>
-                <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+                <meta charset="UTF-8">
                 <title><?php $view['slots']->output('title', 'Test Application') ?></title>
             </head>
             <body>
@@ -311,7 +311,7 @@ output might look like this:
     <!DOCTYPE html>
     <html>
         <head>
-            <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+            <meta charset="UTF-8">
             <title>My cool blog posts</title>
         </head>
         <body>
 
@@ -116,8 +116,7 @@ work:
 * ``2.3``, if you are fixing a bug for an existing feature (you may have
   to choose a higher branch if the feature you are fixing was introduced
   in a later version);
-* ``2.8``, if you are adding a new feature which is backward compatible;
-* ``master``, if you are adding a new and backward incompatible feature.
+* ``master``, if you are adding a new feature.
 
 .. note::
 
 
@@ -11,9 +11,9 @@ Starting from Symfony 2.8, Assetic is no longer included by default in the
 Symfony Standard Edition. Before using any of its features, install the
 AsseticBundle executing this console command in your project:
 
-    .. code-block:: bash
+.. code-block:: bash
 
-        $ composer require symfony/assetic-bundle
+    $ composer require symfony/assetic-bundle
 
 Then, enable the bundle in the ``AppKernel.php`` file of your Symfony application::
 
 
@@ -374,13 +374,15 @@ you need to register it as a service and tag it with :ref:`form.type <dic-tags-f
     .. code-block:: php
 
         // app/config/config.php
-        $definition = new Definition('AppBundle\Form\Type\FriendMessageFormType');
-        $definition->addTag('form.type');
-        $container->setDefinition(
-            'app.form.friend_message',
-            $definition,
-            array('security.token_storage')
+        use Symfony\Component\DependencyInjection\Reference;
+
+        $definition = new Definition(
+            'AppBundle\Form\Type\FriendMessageFormType',
+            array(new Reference('security.token_storage'))
         );
+        $definition->addTag('form.type');
+
+        $container->setDefinition('app.form.friend_message', $definition);
 
 In a controller that extends the :class:`Symfony\\Bundle\\FrameworkBundle\\Controller\\Controller`
 class, you can simply call::
 
@@ -264,7 +264,7 @@ directly in the template that's actually rendering the form.
 
 .. code-block:: html+twig
 
-    {% extends '::base.html.twig' %}
+    {% extends 'base.html.twig' %}
 
     {% form_theme form _self %}
 
@@ -303,7 +303,7 @@ can now re-use the form customization across many templates:
 
 .. code-block:: html+twig
 
-    {# app/Resources/views/Form/fields.html.twig #}
+    {# app/Resources/views/form/fields.html.twig #}
     {% block integer_widget %}
         <div class="integer_widget">
             {% set type = type|default('number') %}
@@ -319,7 +319,7 @@ tell Symfony to use the template via the ``form_theme`` tag:
 
 .. code-block:: html+twig
 
-    {% form_theme form 'AppBundle:Form:fields.html.twig' %}
+    {% form_theme form 'form/fields.html.twig' %}
 
     {{ form_widget(form.age) }}
 
@@ -335,13 +335,12 @@ name of all the templates as an array using the ``with`` keyword:
 
 .. code-block:: html+twig
 
-    {% form_theme form with ['::common.html.twig', ':Form:fields.html.twig',
-                             'AppBundle:Form:fields.html.twig'] %}
+    {% form_theme form with ['common.html.twig', 'form/fields.html.twig'] %}
 
     {# ... #}
 
-The templates can be located at different bundles and they can even be stored
-at the global ``app/Resources/views/`` directory.
+The templates can also be located in different bundles, use the functional name
+to reference these templates, e.g. ``AcmeFormExtraBundle:form:fields.html.twig``.
 
 Child Forms
 ...........
@@ -350,16 +349,16 @@ You can also apply a form theme to a specific child of your form:
 
 .. code-block:: html+twig
 
-    {% form_theme form.child 'AppBundle:Form:fields.html.twig' %}
+    {% form_theme form.child 'form/fields.html.twig' %}
 
 This is useful when you want to have a custom theme for a nested form that's
 different than the one of your main form. Just specify both your themes:
 
 .. code-block:: html+twig
 
-    {% form_theme form 'AppBundle:Form:fields.html.twig' %}
+    {% form_theme form 'form/fields.html.twig' %}
 
-    {% form_theme form.child 'AppBundle:Form:fields_child.html.twig' %}
+    {% form_theme form.child 'form/fields_child.html.twig' %}
 
 .. _cookbook-form-php-theming:
 
@@ -375,9 +374,13 @@ file in order to customize the ``integer_widget`` fragment.
 
 .. code-block:: html+php
 
-    <!-- app/Resources/views/Form/integer_widget.html.php -->
+    <!-- app/Resources/views/form/integer_widget.html.php -->
     <div class="integer_widget">
-        <?php echo $view['form']->block($form, 'form_widget_simple', array('type' => isset($type) ? $type : "number")) ?>
+        <?php echo $view['form']->block(
+            $form,
+            'form_widget_simple',
+            array('type' => isset($type) ? $type : "number")
+        ) ?>
     </div>
 
 Now that you've created the customized form template, you need to tell Symfony
@@ -388,7 +391,7 @@ tell Symfony to use the theme via the ``setTheme`` helper method:
 
 .. code-block:: php
 
-    <?php $view['form']->setTheme($form, array('AppBundle:Form')); ?>
+    <?php $view['form']->setTheme($form, array(':form')); ?>
 
     <?php $view['form']->widget($form['age']) ?>
 
@@ -401,7 +404,14 @@ method:
 
 .. code-block:: php
 
-    <?php $view['form']->setTheme($form['child'], 'AppBundle:Form/Child'); ?>
+    <?php $view['form']->setTheme($form['child'], ':form'); ?>
+
+.. note::
+
+    The ``:form`` syntax is based on the functional names for templates:
+    ``Bundle:Directory``. As the form directory lives in the
+    ``app/Resources/views`` directory, the ``Bundle`` part is empty, resulting
+    in ``:form``.
 
 .. _cookbook-form-twig-import-base-blocks:
 
@@ -475,8 +485,8 @@ Twig
 ~~~~
 
 By using the following configuration, any customized form blocks inside the
-``AppBundle:Form:fields.html.twig`` template will be used globally when a
-form is rendered.
+``form/fields.html.twig`` template will be used globally when a form is
+rendered.
 
 .. configuration-block::
 
@@ -485,14 +495,14 @@ form is rendered.
         # app/config/config.yml
         twig:
             form_themes:
-                - 'AppBundle:Form:fields.html.twig'
+		- 'form/fields.html.twig'
             # ...
 
     .. code-block:: xml
 
         <!-- app/config/config.xml -->
         <twig:config>
-            <twig:form-theme>AppBundle:Form:fields.html.twig</twig:form-theme>
+            <twig:form-theme>form/fields.html.twig</twig:form-theme>
             <!-- ... -->
         </twig:config>
 
@@ -501,7 +511,7 @@ form is rendered.
         // app/config/config.php
         $container->loadFromExtension('twig', array(
             'form_themes' => array(
-                'AppBundle:Form:fields.html.twig',
+		'form/fields.html.twig',
             ),
 
             // ...
@@ -677,7 +687,7 @@ customize the ``name`` field only:
     .. code-block:: html+php
 
         <!-- Main template -->
-        <?php echo $view['form']->setTheme($form, array('AppBundle:Form')); ?>
+        <?php echo $view['form']->setTheme($form, array(':form')); ?>
 
         <?php echo $view['form']->widget($form['name']); ?>
 
@@ -735,7 +745,7 @@ You can also override the markup for an entire field row using the same method:
     .. code-block:: html+php
 
         <!-- Main template -->
-        <?php echo $view['form']->setTheme($form, array('AppBundle:Form')); ?>
+        <?php echo $view['form']->setTheme($form, array(':form')); ?>
 
         <?php echo $view['form']->row($form['name']); ?>
 
 
@@ -422,20 +422,18 @@ both are unique in the database. Unfortunately, the native entity provider
 is only able to handle querying via a single property on the user.
 
 To do this, make your ``UserRepository`` implement a special
 :class:`Symfony\\Component\\Security\\Core\\User\\UserProviderInterface`. This
-interface requires three methods: ``loadUserByUsername($username)``,
-``refreshUser(UserInterface $user)``, and ``supportsClass($class)``::
+:class:`Symfony\\Bridge\\Doctrine\\Security\\User\\UserLoaderInterface`. This
+interface only requires one method: ``loadUserByUsername($username)``::
 
     // src/AppBundle/Entity/UserRepository.php
     namespace AppBundle\Entity;
 
+    use Symfony\Bridge\Doctrine\Security\User\UserLoaderInterface;
     use Symfony\Component\Security\Core\User\UserInterface;
-    use Symfony\Component\Security\Core\User\UserProviderInterface;
     use Symfony\Component\Security\Core\Exception\UsernameNotFoundException;
-    use Symfony\Component\Security\Core\Exception\UnsupportedUserException;
     use Doctrine\ORM\EntityRepository;
 
-    class UserRepository extends EntityRepository implements UserProviderInterface
+    class UserRepository extends EntityRepository implements UserLoaderInterface
     {
         public function loadUserByUsername($username)
         {
@@ -456,30 +454,12 @@ interface requires three methods: ``loadUserByUsername($username)``,
 
             return $user;
         }
-
-        public function refreshUser(UserInterface $user)
-        {
-            $class = get_class($user);
-            if (!$this->supportsClass($class)) {
-                throw new UnsupportedUserException(
-                    sprintf(
-                        'Instances of "%s" are not supported.',
-                        $class
-                    )
-                );
-            }
-
-            return $this->find($user->getId());
-        }
-
-        public function supportsClass($class)
-        {
-            return $this->getEntityName() === $class
-                || is_subclass_of($class, $this->getEntityName());
-        }
     }
 
-For more details on these methods, see :class:`Symfony\\Component\\Security\\Core\\User\\UserProviderInterface`.
+.. versionadded:: 2.8
+    The :class:`Symfony\\Bridge\\Doctrine\\Security\\User\\UserLoaderInterface`
+    was introduced in 2.8. Prior to Symfony 2.8, you had to implement
+    ``Symfony\Component\Security\Core\User\UserProviderInterface``.
 
 .. tip::
 
 
@@ -7,7 +7,6 @@ empty class, you might be tempted to move some code from the front controller
 to it::
 
     // example.com/src/Simplex/Framework.php
-
     namespace Simplex;
 
     use Symfony\Component\Routing;
@@ -33,7 +32,6 @@ to it::
 The front controller code would become more concise::
 
     // example.com/web/front.php
-
     require_once __DIR__.'/../vendor/autoload.php';
 
     use Symfony\Component\HttpFoundation\Request;
@@ -94,7 +92,6 @@ container:
 Create a new file to host the dependency injection container configuration::
 
     // example.com/src/container.php
-
     use Symfony\Component\DependencyInjection;
     use Symfony\Component\DependencyInjection\Reference;
 
@@ -147,7 +144,6 @@ it in other object definitions.
 The front controller is now only about wiring everything together::
 
     // example.com/web/front.php
-
     require_once __DIR__.'/../vendor/autoload.php';
 
     use Symfony\Component\HttpFoundation\Request;
@@ -165,7 +161,6 @@ As all the objects are now created in the dependency injection container, the
 framework code should be the previous simple version::
 
     // example.com/src/Simplex/Framework.php
-
     namespace Simplex;
 
     use Symfony\Component\HttpKernel\HttpKernel;