updating from Symfony-docs (last part)

README.markdown

@@ -8,8 +8,9 @@ Contribuer
 
 >**Note**
 >A moins que vous ne documentiez une fonctionnalité qui est nouvelle dans
-> une sous-version de Symfony 2, toutes les « pull requests » doivent être basées sur la
->branche **2.0**, **et non pas** sur la branche master ou la branche 2.1.
+>une version spécifique de Symfony (ex Symfony 2.1), toutes les « pull requests »
+>doivent être basées sur la branche **2.0**, **et non pas** sur la branche
+>master ou la branche 2.1.
 
 Nous adorons les contributeurs ! Pour plus d'informations sur la manière
 dont vous pouvez contribuer à la documentation de Symfony, veuillez lire

book/controller.rst

@@ -78,7 +78,7 @@ route qui fasse correspondre une URL à ce dernier (#2).
 .. note::
 
     Bien que nommé de la même manière, un « contrôleur frontal » est différent
-    des « contrôleurs » dont nous allons parler dans ce chapitre. Un contrôleur
+    des « contrôleurs » abordés dans ce chapitre. Un contrôleur
     frontal est un petit fichier PHP qui se situe dans votre répertoire web et
     à travers lequel toutes les requêtes sont dirigées. Une application typique
     va avoir un contrôleur frontal de production (par exemple: ``app.php``) et
@@ -214,11 +214,8 @@ Les paramètres de la route en tant qu'arguments du contrôleur
 Vous savez déjà que le paramètre ``_controller`` ``AcmeHelloBundle:Hello:index``
 réfère à une méthode ``HelloController::indexAction()`` qui réside dans le bundle
 ``AcmeHelloBundle``. Mais ce qui est plus intéressant sont les arguments qui sont passés
-à cette méthode :
+à cette méthode::
 
-.. code-block:: php
-
-    <?php
     // src/Acme/HelloBundle/Controller/HelloController.php
     namespace Acme\HelloBundle\Controller;
 
@@ -371,9 +368,7 @@ dont elle pourrait avoir besoin. En étendant cette classe ``Controller``, vous
 pouvez tirer parti de plusieurs méthodes d'aide (« helper »).
 
 Ajoutez le mot-clé ``use`` au-dessus de la classe ``Controller`` et modifiez
-``HelloController`` pour qu'il l'étende :
-
-.. code-block:: php
+``HelloController`` pour qu'il l'étende::
 
     // src/Acme/HelloBundle/Controller/HelloController.php
     namespace Acme\HelloBundle\Controller;
@@ -402,14 +397,13 @@ elle-même.
 
     Étendre la classe de base est *optionnel* dans Symfony; elle contient
     des raccourcis utiles mais rien d'obligatoire. Vous pouvez aussi étendre
-    ``Symfony\Component\DependencyInjection\ContainerAware``. L'objet conteneur
-    de service (« service container ») sera ainsi accessible à travers la
-    propriété ``container``.
+    :class:`Symfony\\Component\\DependencyInjection\\ContainerAware`. L'objet
+    conteneur de service (« service container ») sera ainsi accessible à travers
+    la propriété ``container``.
 
 .. note::
 
-    Vous pouvez aussi définir vos :doc:`Contrôleurs en tant que Services
-    </cookbook/controller/service>`.
+    Vous pouvez aussi définir vos :doc:`Contrôleurs en tant que Services</cookbook/controller/service>`.
 
 .. index::
    single: Controller; Common tasks
@@ -456,9 +450,7 @@ Afin d'exécuter une redirection 301 (permanente), modifiez le second argument :
 
     La méthode ``redirect()`` est simplement un raccourci qui crée un objet
     ``Response`` spécialisé dans la redirection d'utilisateur. Cela revient
-    à faire :
-
-    .. code-block:: php
+    à faire::
 
         use Symfony\Component\HttpFoundation\RedirectResponse;
 
@@ -729,7 +721,7 @@ pour délivrer le message ``notice`` :
 
     .. code-block:: php
     
-        <?php foreach ($view['session']->getFlashBag()->get('notice') as $message): ?>
+        <?php foreach ($view['session']->getFlash('notice') as $message): ?>
             <div class="flash-notice">
                 <?php echo "<div class='flash-error'>$message</div>" ?>
             </div>

book/doctrine.rst

@@ -180,12 +180,6 @@ et ses propriétés doivent être mappées avec la base de données. Ces métado
 peuvent être spécifiées dans de nombreux formats incluant le YAML, XML ou directement
 dans la classe ``Product`` avec les annotations :
 
-.. note::
-
-    Un bundle ne peut accepter qu'un format de définition des métadonnées. Par 
-    exemple, il n'est pas possible de mélanger des définitions au format YAML
-    avec des entités annotées dans les classes PHP.
-
 .. configuration-block::
 
     .. code-block:: php-annotations
@@ -262,6 +256,12 @@ dans la classe ``Product`` avec les annotations :
             </entity>
         </doctrine-mapping>
 
+.. note::
+
+    Un bundle ne peut accepter qu'un format de définition des métadonnées. Par 
+    exemple, il n'est pas possible de mélanger des définitions au format YAML
+    avec des entités annotées dans les classes PHP.
+
 .. tip::
 
     Le nom de la table est optionnel et si il est omis il sera déterminé automatiquement
@@ -307,6 +307,7 @@ disponibles, reportez vous à la section :ref:`book-doctrine-field-types`.
          * @IgnoreAnnotation("fn")
          */
         class Product
+        // ...
 
 Générer les getters et setters
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -331,10 +332,10 @@ pas (c.à.d qu'elle ne remplace pas les méthodes existantes)
 
     Avec la commande ``doctrine:generate:entities``, vous pouvez :
 
-        * générer les getters et setters,
+        * générer les getters et setters;
 
         * générer les classes repository configurées avec les annotations
-            ``@ORM\Entity(repositoryClass="...")``,
+            ``@ORM\Entity(repositoryClass="...")``;
 
         * générer les constructeurs appropriés pour les relations 1:n et n:m.
 
@@ -435,11 +436,11 @@ suivante au ``DefaultController`` du bundle :
 Décortiquons cet exemple :
 
 * **lignes 9 à 12** Dans cette section, vous instanciez et travaillez avec l'objet
-  ``product`` comme n'importe quel autre objet PHP normal;
+  ``product`` comme n'importe quel autre objet PHP normal.
 
 * **ligne 14** Cette ligne récupère un objet *gestionnaire d'entités* (entity manager)
   de Doctrine, qui est responsable de la gestion du processus de persistence et de récupération
-  des objets vers et depuis la base de données;
+  des objets vers et depuis la base de données.
 
 * **ligne 15** La méthode ``persist()`` dit à Doctrine de « gérer » l'objet ``product``.
   Cela ne crée pas vraiment de requête dans la base de données (du moins pas encore).
@@ -448,7 +449,7 @@ Décortiquons cet exemple :
   les objets qu'il gère pour savoir si ils ont besoin d'être persistés dans la base
   de données. Dans cet exemple, l'objet ``$product`` n'a pas encore été persisté,
   le gestionnaire d'entités éxecute donc une requête ``INSERT`` et une ligne est créée dans
-  la table ``product``
+  la table ``product``.
 
 .. note::
 
@@ -587,9 +588,9 @@ une action de mise à jour dans un contrôleur :
 
 Mettre à jour l'objet ne nécessite que trois étapes :
 
-1. Récupérer l'objet depuis Doctrine;
-2. Modifier l'objet;
-3. Apeller la méthode ``flush()`` du gestionnaire d'entités
+#. Récupérer l'objet depuis Doctrine;
+#. Modifier l'objet;
+#. Apeller la méthode ``flush()`` du gestionnaire d'entités
 
 Notez qu'apeller ``$em->persist($product)`` n'est pas nécessaire. Souvenez-vous que
 cette méthode dit simplement à Doctrine de gérer, ou « regarder » l'objet ``$product``.

book/forms.rst

@@ -27,9 +27,7 @@ de choses à faire ») simple qui doit afficher des « tâches ». Parce que vos
 utilisateurs devront éditer et créer des tâches, vous allez avoir besoin de
 construire des formulaires. Mais avant de commencer, concentrez-vous
 d'abord sur la classe générique ``Task`` qui représente et stocke les données
-pour une tâche :
-
-.. code-block:: php
+pour une tâche::
 
     // src/Acme/TaskBundle/Entity/Task.php
     namespace Acme\TaskBundle\Entity;
@@ -839,9 +837,7 @@ Comme vous l'avez vu, un formulaire peut être créé et utilisé directement da
 un contrôleur. Cependant, une meilleure pratique est de construire le formulaire
 dans une classe PHP séparée et autonome, qui peut ainsi être réutilisée n'importe
 où dans votre application. Créez une nouvelle classe qui va héberger la logique
-de construction du formulaire « task » :
-
-.. code-block:: php
+de construction du formulaire « task »::
 
     // src/Acme/TaskBundle/Form/Type/TaskType.php
     namespace Acme\TaskBundle\Form\Type;
@@ -866,9 +862,7 @@ de construction du formulaire « task » :
 Cette nouvelle classe contient toutes les directives nécessaires à la création
 du formulaire « task » (notez que la méthode ``getName()`` doit retourner un
 identifiant unique pour ce « type » de formulaire). Il peut être utilisé pour
-construire rapidement un objet formulaire dans le contrôleur :
-
-.. code-block:: php
+construire rapidement un objet formulaire dans le contrôleur::
 
     // src/Acme/TaskBundle/Controller/DefaultController.php
 
@@ -921,14 +915,14 @@ manière de créer des formulaires, mais le choix final vous revient.
     Dans le cas où vous avez besoin de champs supplémentaires dans le formulaire
     (par exemple une checkbox « Acceptez vous les conditions d'utilisation ») qui
     ne doi pas être mappé à l'objet sous-jacent, vous devez définir l'option
-    property_path setting à ``false``::
+    ``mapped`` setting à ``false``::
 
         use Symfony\Component\Form\FormBuilderInterface;
 
         public function buildForm(FormBuilderInterface $builder, array $options)
         {
             $builder->add('task');
-            $builder->add('dueDate', null, array('property_path' => false));
+            $builder->add('dueDate', null, array('mapped' => false));
         }
 
     De plus, s'il y a des champs dans le formulaire qui ne sont pas inclus dans
@@ -1090,12 +1084,12 @@ instance de la nouvelle classe ``CategoryType`` :
 
 Les champs de ``CategoryType`` peuvent maintenant être affichés à côté de ceux
 de la classe ``TaskType``. Pour activer la validation sur CategoryType, ajoutez
-l'option ``cascade_validation``::
+l'option ``cascade_validation`` à ``TaskType``::
 
     public function setDefaultOptions(OptionsResolverInterface $resolver)
     {
         $resolver->setDefaults(array(
-            'data_class' => 'Acme\TaskBundle\Entity\Category',
+            'data_class' => 'Acme\TaskBundle\Entity\Task',
             'cascade_validation' => true,
         ));
     }
@@ -1210,7 +1204,7 @@ des champs via la fonction ``form_row``. Pour dire au composant formulaire
 d'utiliser votre nouveau fragment ``form_row`` defini ci-dessus, ajoutez
 ce qui suit en haut du template qui rend le formulaire :
 
-.. configuration-block:: php
+.. configuration-block::
 
     .. code-block:: html+jinja
 
@@ -1546,7 +1540,7 @@ votre projet. Pour plus d'informations, voir la section de
     L'option ``intention`` est optionnelle mais améliore grandement la sécurité
     du jeton généré en le rendant différent pour chaque formulaire.
 
-.. index:
+.. index::
    single: Forms; With no class
 
 Utiliser un formulaire sans classe
@@ -1588,10 +1582,10 @@ Par défaut, en fait, un formulaire part du principe que vous voulez travailler
 un tableau de données plutôt qu'avec un objet.Il y a exactement deux façons de changer
 ce comportement et d'associer le formulaire avec un objet à la place:
 
-1. Passez un objet lors de la création du formulaire (comme premier argument de ``createFormBuilder``
+#. Passez un objet lors de la création du formulaire (comme premier argument de ``createFormBuilder``
    ou deuxième argument de ``createForm``);
 
-2. Définissez l'option ``data_class`` de votre formulaire.
+#. Définissez l'option ``data_class`` de votre formulaire.
 
 Si vous ne faites *pas* l'un ou l'autre, alors le formulaire retournera les données
 dans un tableau. Dans cet exemple, puisque ``$defaultData`` n'est pas un objet (et
@@ -1601,9 +1595,7 @@ finalement un tableau.
 .. tip::
 
     Vous pouvez également accéder directement aux valeurs POST (dans ce cas "name")
-    par le biais de l'objet Request, comme ceci :
-
-    .. code-block:: php
+    par le biais de l'objet Request, comme ceci::
 
         $this->get('request')->request->get('name');
 
@@ -1635,7 +1627,7 @@ mais voici un petit exemple::
 
     // créez un formulaire, sans valeurs par défaut, et passez les contraintes
     $form = $this->createFormBuilder(null, array(
-        'validation_constraint' => $collectionConstraint,
+        'constraints' => $collectionConstraint,
     ))->add('email', 'email')
         // ...
     ;
@@ -1667,7 +1659,7 @@ surchargez la méthode ``setDefaultOptions`` pour les spécifier :
             ));
         
             $resolver->setDefaults(array(
-                'validation_constraint' => $collectionConstraint
+                'constraints' => $collectionConstraint
             ));
         }
     }