Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Correction symblog partie 2 #2

Merged
merged 2 commits into from

2 participants

@j4zBen

Bonjour Clément
voici la suite, cordialement, Ben.

@Keirua Keirua merged commit f61f4cd into from
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on May 16, 2012
  1. @j4zBen
  2. @j4zBen
This page is out of date. Refresh to see the latest.
Showing with 95 additions and 102 deletions.
  1. +37 −43 docs/doctrine-2-et-les-articles.rst
  2. +58 −59 docs/validateurs-et-formulaires.rst
View
80 docs/doctrine-2-et-les-articles.rst
@@ -5,13 +5,12 @@ Introduction
------------
Dans ce chapitre, nous allons commencer à explorer le modèle d'article. Ce modèle sera implémenté en utilisant l'ORM (pour Object Relation Mapper, soit ``Lien Objet-Relation``) `Doctrine 2 <http://www.doctrine-project.org/projects/orm>`_ .
-Doctrine 2 nous permet de faire persister nos objets PHP. Il propose également un dialecte SQL personnel appelé DQL (pour Doctrine Query Language, ou ``Langage de requêtes de Doctrine``). En plus de Doctrine 2, nous allons également aborder le concept de données factices (data fixtures). C'est un mécanisme qui permet de peupler la base de donnée de l'environnement de développement et de test avec des données de test adéquates. A la fin de ce chapitre nous aurons défini le modèle d'article et mis à jour la base de donnée afin qu'elle reflète ce changement, et créé des articles factices. Nous aurons également construit les bases de la page d'affichage des article.
+Doctrine 2 nous permet de faire persister nos objets PHP. Il propose également un dialecte SQL personnel appelé DQL (pour Doctrine Query Language, ou ``Langage de requêtes de Doctrine``). En plus de Doctrine 2, nous allons également aborder le concept de données factices (data fixtures). C'est un mécanisme permettant de peupler la base de donnée de l'environnement de développement et de test avec des données de test adéquates. A la fin de ce chapitre nous aurons défini le modèle d'article, mis à jour la base de donnée afin qu'elle reflète ce changement, et créé des articles factices. Nous aurons également construit les bases de la page d'affichage des article.
Doctrine 2: Le modèle
---------------------
-Afin que notre blog fonction, il nous faut un moyen de faire persister les données. Doctrine 2 fournit une librairie d'ORM conçue exactement dans cette optique. Doctrine 2 est conçu par dessus une très puissante
-`couche d'abstraction de base de donnée <http://www.doctrine-project.org/projects/dbal>`_ qui la rend indépendante de la base de donnée utilisée : cela permet d'utiliser différents moteurs de stockage tels que MySQL, PostgreSQL ou SQLite. Nous allons utiliser MySQL dans ce tutorial, mais n'importe quel moteur peut être utilisé à la place.
+Afin que notre blog fonctionne, il nous faut un moyen de faire persister les données. Doctrine 2 fournit une librairie d'ORM conçue exactement dans cette optique. Doctrine 2 est conçu au dessus d'une `couche d'abstraction de base de donnée <http://www.doctrine-project.org/projects/dbal>`_ très puissante qui la rend indépendante de la base de donnée utilisée : cela permet d'utiliser différents moteurs de stockage tels que MySQL, PostgreSQL ou SQLite. Nous allons utiliser MySQL dans ce tutorial, mais n'importe quel moteur peut être utilisé à la place.
.. tip::
@@ -21,8 +20,7 @@ Afin que notre blog fonction, il nous faut un moyen de faire persister les donn
"Un mapping objet-relationnel (en anglais object-relational mapping ou ORM) est une technique de programmation informatique qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé. On pourrait le désigner par `` correspondance entre monde objet et monde relationnel ``"
- Ce qu'un ORM facilite, c'est la traduction des données d'une base de donnée relationnelle en des objets PHP que l'on peut manipuler. Cela permet d'encapsuler des opérations que l'on souhaite réaliser sur une table à l'intérieur d'une classe. Prenons l'exemple d'une table pour les utilisateurs. Elle contiendra probablement des chamsp tels que le nom d'utilisateur, son mot de passe, son nom et sa date de naissance. L'orm va nous permettre, dans la classe PHP, d'appeller des méthodes ``getUsername()``
- ou ``setPassword()``. Les ORM vont bien plus loin que cela néanmoins, elles permettent de retrouver des entités liées pour nous, soit au moment où l'on charge l'entité utilisateur, soit de manière paresseuse par la suite. Maintenant imaginons que notre utilisateur a des amis qui lui sont liés. Il peut y avoir une table d'amis, où est stockée la clée primaire de la table utilisateur. L'ORM nous permet d'utiliser une méthode telle que ``$user->getFriends()`` pour récupérer les objets de la table d'amis. Si cela ne suffit pas, l'ORM se charge également de la persistance, ce qui nous permet de créer des objets PHP, d'appeler une méthode de sauvegarde (du genre ``save()``), et de laisser l'ORM s'occuper des détails pour la sauvegarde dans la base de données. Comme nous allons utiliser Doctrine 2 comme librairie d'ORM, vous allez devenir plus à l'aise avec cette notion au cours de ce tutoriel.
+ Ce qu'un ORM facilite, c'est la traduction des données d'une base de donnée relationnelle en des objets PHP que l'on peut manipuler. Cela permet d'encapsuler des opérations que l'on souhaite réaliser sur une table à l'intérieur d'une classe. Prenons l'exemple d'une table pour gérer les utilisateurs. Elle contiendra probablement des champs tels que le nom d'utilisateur, son mot de passe, son nom et sa date de naissance. L'orm va nous permettre d'appeller des méthodes ``getUsername()`` ou ``setPassword()`` dans la classe PHP. Les ORM vont bien plus loin que cela néanmoins, ils permettent de retrouver des entités liées pour nous, soit au moment où l'on charge l'entité utilisateur, soit de manière retardée par la suite. Maintenant imaginons que notre utilisateur a des amis qui lui sont liés. Il peut y avoir une table d'amis, où est stockée la clée primaire de la table utilisateur. L'ORM nous permet d'utiliser une méthode telle que ``$user->getFriends()`` pour récupérer les objets de la table d'amis. Si cela ne suffit pas, l'ORM se charge également de la persistance, ce qui nous permet de créer des objets PHP, d'appeler une méthode de sauvegarde (du genre ``save()``), et de laisser l'ORM s'occuper des détails pour la sauvegarde dans la base de données. Comme nous allons utiliser Doctrine 2 comme librairie d'ORM, vous allez devenir plus à l'aise avec cette notion au cours de ce tutoriel.
.. note::
@@ -131,14 +129,14 @@ Avant de lancer cette commande, il faut expliquer à Doctrine 2 comment l'entit
protected $updated;
}
-Tout d'abord, on importe et crée un alias pour l'espace de nom de Doctrine 2. Cela nous permet d'utiliser les ``annotations`` pour décrire les métadonnées des entités. Les métadonnées nous fournissent des informations sur comment les membres sont représentés dans la base de donnée.
+Tout d'abord, on importe et crée un alias pour l'espace de nom de Doctrine 2. Cela nous permet d'utiliser les ``annotations`` pour décrire les métadonnées des entités. Les métadonnées nous fournissent des informations sur la manière dont les membres sont représentés dans la base de donnée.
.. tip::
Nous venons seulement de voir un petit sous ensemble des types d'association que propose Doctrine 2. Une `liste complète <http://www.doctrine-project.org/docs/orm/2.0/en/reference/basic-mapping.html#doctrine-mapping-types>`_
- est disponible sur le site web de Doctrine 2. Nous allons utiliser d'autres types d'association plus tard dans ce tutorial.
+ est disponible sur le site web de Doctrine 2. Nous allons utiliser d'autres types d'association plus tard dans ce tutoriel.
-L'oeil averti aura sûrement remarqué que l'attribut ``$comments`` n'a pas de métadonnées associes. C'est car il n'est pas nécessaire de le faire persister dans la base de données. Il fournit en effet seulement une liste des commentaires relatifs à un article. Si l'on pense en terme d'objet et non de base de donnée, cela prend tout son sens, comme vous pouvez le voir dans le bout de code suivant :
+L'oeil averti aura sûrement remarqué que l'attribut ``$comments`` n'a pas de métadonnées associées. Nous ne souhaitons pas le faire persister dans la base de données. En effet, il fournit seulement une liste des commentaires relatifs à un article. Si l'on pense en terme d'objet et non de base de données, cela prend tout son sens, comme vous pouvez le voir dans le bout de code suivant :
.. code-block:: php
@@ -153,7 +151,7 @@ L'oeil averti aura sûrement remarqué que l'attribut ``$comments`` n'a pas de m
$comment->setComment("Symfony2 rocks!");
$blog->addComment($comment);
-La portion de code ci dessus présente le comporte normal que l'on pourrait avoir d'une classe d'article et de commentaires. En interne, la méthode ``$blog->addComment()`` pourrait être implémentée comme ceci :
+La portion de code ci-dessus illustre le comporte normal que l'on pourrait souhaiter d'une classe d'article et de commentaires. En interne, la méthode ``$blog->addComment()`` pourrait être implémentée comme ceci :
.. code-block:: php
@@ -167,7 +165,7 @@ La portion de code ci dessus présente le comporte normal que l'on pourrait avoi
}
}
-La méthode ``addComment`` se contente d'ajouter un objet ``Commentaire`` à la variable membre ``$comments`` de l'article. Récupérer les commentaires est alors très simple :
+La méthode ``addComment`` se contente d'ajouter un objet ``Comment`` à la variable membre ``$comments`` de l'article. Récupérer les commentaires est alors très simple :
.. code-block:: php
@@ -213,7 +211,7 @@ La base de données
Création de la base de données
..............................
-Si vous avez suivi le chapitre 1 de ce tutorial, vous avez dû utiliser l'outil de configuration web pour rentrer les paramètres de la base de donnée. Si vous ne l'avez pas fait, mettez à jour les options ``database_*`` dans le fichier de configuration ``app/parameters.ini``.
+Si vous avez suivi le chapitre 1 de ce tutoriel, vous avez dû utiliser l'outil de configuration web pour rentrer les paramètres de la base de donnée. Si vous ne l'avez pas fait, mettez à jour les options ``database_*`` dans le fichier de configuration ``app/parameters.ini``.
Il est maintenant temps de créer la base de donnée en utilisant une autre commande Doctrine 2. Cette commande crée seulement la base de données, mais pas les tables à l'intérieur. Si une base de donnée du même nom existe déjà, une erreur sera affichée et la base de donnée existante restera intacte.
@@ -221,7 +219,7 @@ Il est maintenant temps de créer la base de donnée en utilisant une autre comm
$ php app/console doctrine:database:create
-Nous sommes maintenant prêts pour créer la représentation de l'entité ``Blog`` dans la base de données. Il y a 2 moyens de faire cela. Nous pouvons soit utiliser la commande ``schema`` de Doctrine 2 pour mettre à jour la base de donnée, ou bien utiliser les bien plus puissantes migrations de Doctrine 2. Pour le moment, nous allons nous contenter de la commande ``schema``, les migrations seront abordées dans un chapitre ultérieur.
+Nous sommes maintenant prêts pour créer la représentation de l'entité ``Blog`` dans la base de données. Il y a 2 moyens pour faire cela. Nous pouvons utiliser la commande ``schema`` de Doctrine 2 pour mettre à jour la base de donnée, ou bien les nettement plus puissantes migrations de Doctrine 2. Pour le moment, contentons nous de la commande ``schema``, les migrations seront abordées dans un chapitre ultérieur.
Création de la table d'article
..............................
@@ -232,7 +230,7 @@ Pour créer la table ``blog`` dans notre base de données, on peut lancer la com
$ php app/console doctrine:schema:create
-Cela exécute le code SQL nécessaire à la génération du schéma de la base de donnée pour l'entité ``blog``. Vous pouvez également ajouter l'argument ``--dump-sql`` optionnellement afin d'afficher le code SQL généré. Si vous regardez maintenant le contenu de votre base de données, vous pourrez voir que la table ``blog`` a été créée, avec des champs qui correspondent à ce que nous avions spécifié.
+Cela exécute le code SQL nécessaire à la génération du schéma de la base de donnée pour l'entité ``blog``. Vous pouvez également ajouter l'argument ``--dump-sql`` optionnellement afin d'afficher le code SQL généré. Si vous regardez le contenu de votre base de données, vous pourrez voir que la table ``blog`` a été créée, avec des champs qui correspondent à ce que nous avions spécifié.
.. tip::
@@ -242,7 +240,7 @@ Cela exécute le code SQL nécessaire à la génération du schéma de la base d
$ php app/console doctrine:schema:create --help
- Les informations d'aide vont alors afficher l'usage et les options disponible. La plupart des commandes proposent un grand nombre d'options qui permettent de personnaliser l'exécution d'une commande.
+ Les informations d'aide vont alors afficher l'usage et les options disponible. La plupart des commandes proposent un grand nombre d'options permettant de personnaliser l'exécution d'une commande.
Intégration du Modèle avec la Vue : affichage d'un article
----------------------------------------------------------
@@ -252,7 +250,7 @@ Maintenant que l'entité ``Blog`` a été créée et que la base de donnée le r
La route d'affichage d'un article
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Nous allons commencer par créer une route pour l'action ``show``. Un article va être identifié par un identifiant unique, cet identifiant se doit donc d'être présent dans l'URL. Mettez à jour les règles de routage du ``BloggerBlogBundle`` dans ``src/Blogger/BlogBundle/Resources/config/routing.yml`` en y ajoutant ce qui suit:
+Nous allons commencer par créer une route pour l'action ``show``. Un article va être caractérisé par un identifiant unique, cet identifiant se doit donc d'être présent dans l'URL. Mettez à jour les règles de routage du ``BloggerBlogBundle`` dans ``src/Blogger/BlogBundle/Resources/config/routing.yml`` en y ajoutant ce qui suit:
with the following
.. code-block:: yaml
@@ -265,12 +263,12 @@ with the following
_method: GET
id: \d+
-Comme l'identifiant de l'article doit être présent dans l'URL, nous avons précisé un qu'un élément ``id`` serait présent. Sans plus de détails, cela signifie que les adresse ``http://symblog.co.uk/1`` et ``http://symblog.co.uk/my-blog`` valident toute les deux la route. Comme nous savons que l'identifiant est un entier (c'est ce que l'on a défini dans le mapping), on peut ajouter une contrainte qui ne valide la route que si le paramètre ``id`` est un entier. C'est réalisé grâce à la ligne ``id: \d+`` dans la section ``requirements``, qui définit des conditions à valider. Maintenant, seul la première adresse serait valide. Vous pouvez également voir que lorsque l'adresse valide cette route, c'est la méthode ``show`` du controller ``Blog`` du ``BloggerBlogBundle`` qui est executée. Plus qu'à créer le controlleur ``Blog``, c'est ce que nous allons faire tout de suite.
+Comme l'identifiant de l'article sera présent dans l'URL, nous avons ajouté un élément ``id`` dans la route. Sans plus de détail, cela signifie que les adresses ``http://symblog.co.uk/1`` et ``http://symblog.co.uk/my-blog`` valident toutes les deux la route. Comme nous savons que l'identifiant est un entier (c'est ce que l'on a défini dans le mapping), on peut ajouter une contrainte qui ne valide la route que si le paramètre ``id`` est un entier. C'est réalisé grâce à la ligne ``id: \d+`` dans la section ``requirements``, qui définit les conditions à valider. Maintenant, seule la première adresse serait valide. Vous pouvez également voir que lorsque l'adresse valide cette route, c'est la méthode ``show`` du contrôleur ``Blog`` du ``BloggerBlogBundle`` qui est executée. Il ne reste plus qu'à créer le contrôleur ``Blog``, c'est ce que nous allons faire tout de suite.
-L'action ``Show`` du Controlleur
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+L'action ``Show`` du Contrôleur
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Le lien entre le Modèle et la Vue, c'est le Controlleur, c'est donc là que nous allons commencer à créer la page d'affichage. Nous pourrions ajouter l'action ``show`` à notre controlleur ``Page`` déjà existant, mais comme cette page se contente d'afficher les entités ``blog``, cela a plus de sens de le mettre dans un controlleur à part.
+Le lien entre le Modèle et la Vue, c'est le Contrôleur, c'est donc là que nous allons commencer à créer la page d'affichage. Nous pourrions ajouter l'action ``show`` à notre contrôleur ``Page`` déjà existant, mais comme cette page se contente d'afficher les entités ``blog``, cela a plus de sens de le mettre dans un contrôleur à part.
Créez un nouveau fichier dans ``src/Blogger/BlogBundle/Controller/BlogController.php`` et collez-y le code suivant :
@@ -307,11 +305,11 @@ Créez un nouveau fichier dans ``src/Blogger/BlogBundle/Controller/BlogControlle
}
}
-Nous avons crée un nouveau controlleur pour l'entité ``Blog``, et y avons défini une action ``show``. Comme nous avons spécifié un paramètre ``id`` pour la route ``BloggerBlogBundle_blog_show``, ce paramètre sera passé en argument à la méthode ``showAction``. Si nous avions passé plusieurs paramètres dans la règle de routage, ils auraient également été fournis sous la forme d'arguments séparés.
+Nous avons créé un nouveau contrôleur pour l'entité ``Blog``, et y avons défini une action ``show``. Comme nous avons spécifié un paramètre ``id`` pour la route ``BloggerBlogBundle_blog_show``, ce paramètre sera passé en argument à la méthode ``showAction``. Si nous avions passé plusieurs paramètres dans la règle de routage, ils auraient également été fournis sous la forme d'arguments séparés.
.. tip::
- Les actions du controlleur fournissent également un objet de type ``Symfony\Component\HttpFoundation\Request`` si vous le spécifiez parmi les paramètres. Cela peut être utile lorsque l'on traite avec les formulaires. Nous en avons déjà utilisé dans le chapitre 2, mais nous ne nous sommes pas servis de cette méthode car nous avons utilisé une des méthodes d'aide du controlleur de base
+ Les actions du contrôleur fournissent également un objet de type ``Symfony\Component\HttpFoundation\Request`` si vous le spécifiez parmi les paramètres. Cela peut être utile lorsque l'on traite avec les formulaires. Nous en avons déjà utilisé dans le chapitre 2, mais nous ne nous sommes pas servis de cette méthode car nous avons utilisé une des méthodes d'aide du contrôleur de base
``Symfony\Bundle\FrameworkBundle\Controller\Controller`` comme suit :
.. code-block:: php
@@ -339,13 +337,13 @@ Nous avons crée un nouveau controlleur pour l'entité ``Blog``, et y avons déf
Les deux méthodes réalisent la même tâche, mais si votre controlleur n'étendait pas la classe de base ``Symfony\Bundle\FrameworkBundle\Controller\Controller``, vous ne pourriez pas utiliser la première méthode.
Il nous faut ensuite récupérer les entités ``Blog`` dans la base de données. Nous utilisons pour cela une seconde méthode de la classe ``Symfony\Bundle\FrameworkBundle\Controller\Controller`` pour obtenir le gestionnaire d'entités de Doctrine 2. Le but du
-`gestionnaire d'entités <http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html>`_ est de récupérer les objets venant de la base de donnée, et de les y faire persister. Nous utilisons ensuite l'objet ``EntityManger`` pour obtenir le ``Repository`` de Doctrine2 pour l'entité ``BloggerBlogBundle:Blog``. La syntaxe spécifiée ici est simplement un raccourci qui peut être utilisé avec Doctrine 2 au lieu de préciser le nom entier, c'est à dire ``Blogger\BlogBundle\Entity\Blog``. Avec le dépot d'objets (le repository), nous appelons la méthode ``find()`` avec pour argument la variable ``$id``. Cette méthode se charge de retrouver tous les objets à partir de leur clé primaire.
+`gestionnaire d'entités <http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html>`_ est de récupérer les objets venant de la base de données, et de les y faire persister. Nous utilisons ensuite l'objet ``EntityManger`` pour obtenir le ``Repository`` de Doctrine2 pour l'entité ``BloggerBlogBundle:Blog``. La syntaxe spécifiée ici est simplement un raccourci qui peut être utilisé avec Doctrine 2 au lieu de préciser le nom entier, c'est à dire ``Blogger\BlogBundle\Entity\Blog``. Avec le dépot d'objets (le repository), nous appelons la méthode ``find()`` avec pour argument la variable ``$id``. Cette méthode se charge de retrouver tous les objets à partir de leur clé primaire.
Enfin, nous vérifions qu'une entité a été trouvé, et fournissons cette entité à la vue. Si aucune entité n'est trouvée, une exception est lancée, qui va se charger de générer une ``erreur 404``.
.. tip::
- L'objet repository (le dépot d'objet) nous donne accès à un certain nombre de méthodes auxilliaires utiles, tel que :
+ L'objet repository (le dépot d'objet) nous donne accès à un certain nombre de méthodes auxilliaires utiles, telles que :
.. code-block:: php
@@ -360,7 +358,7 @@ Enfin, nous vérifions qu'une entité a été trouvé, et fournissons cette enti
La vue
~~~~~~
-Maintenant que nous avons construit l'action ``show`` pour le controlleur ``Blog``, nous pouvons nous concenter sur l'affichage des entités ``Blog``. Comme précisé dans l'action ``show``, le template ``BloggerBlogBundle:Blog:show.html.twig`` sera affiché. Commençons par créer ce fichier, dans ``src/Blogger/BlogBundle/Resouces/views/Blog/show.html.twig``, et ajoutons y le code qui suit :
+Maintenant que nous avons construit l'action ``show`` pour le contrôleur ``Blog``, nous pouvons nous concenter sur l'affichage des entités ``Blog``. Comme précisé dans l'action ``show``, le template ``BloggerBlogBundle:Blog:show.html.twig`` sera affiché. Commençons par créer ce fichier, dans ``src/Blogger/BlogBundle/Resouces/views/Blog/show.html.twig``, et ajoutons y le code qui suit :
.. code-block:: html
@@ -387,7 +385,7 @@ Comme vous l'attendiez, nous commençons par étendre le template principale du
CSS
...
-Afin que la page d'affichage des articles soit agréable au regarde, il faut lui ajouter du style. Mettez à jour la feuille de style dans ``src/Blogger/BlogBundle/Resouces/public/css/blog.css`` avec le contenu suivant :
+Afin que la page d'affichage des articles soit visuellement agréable, il faut lui ajouter du style. Mettez à jour la feuille de style dans ``src/Blogger/BlogBundle/Resouces/public/css/blog.css`` avec le contenu suivant :
.. code-block:: css
@@ -409,15 +407,15 @@ Afin que la page d'affichage des articles soit agréable au regarde, il faut lui
$ php app/console assets:install web
-Comme nous avons maintenant construit le controlleur et la vue pour l'action ``show``, allons jeter un oeil à la page que nous venos de créer. Rendez vous avec votre navigateur à l'adresse ``http://symblog.dev/app_dev.php/1``. Ce n'est probablement pas la page que vous attendiez...
+Comme nous avons maintenant construit le contrôleur et la vue pour l'action ``show``, allons jeter un oeil à la page que nous venons de créer. Rendez vous avec votre navigateur à l'adresse ``http://symblog.dev/app_dev.php/1``. Ce n'est probablement pas la page que vous attendiez...
.. image:: /_static/images/part_3/404_not_found.jpg
:align: center
:alt: Symfony2 404 Not Found Exception
-Symfony2 a généré une erreur 404. Comme il n'y a rien dans la base de donnée, il n'y a pas d'entité ayant pour ``id`` la valeur 1.
+Symfony2 a généré une erreur 404. Comme il n'y a rien dans la base de données, il n'y a pas d'entité ayant pour ``id`` la valeur 1.
-Vous pourriez simplement ajouter un élément dans la table ``blog`` de votre base de donnée, mais nous allons faire mieux. Nous servir de données factices, également appelées les ``data fixtures``.
+Vous pourriez simplement ajouter un élément dans la table ``blog`` de votre base de données, mais nous allons faire mieux. Nous servir de données factices, également appelées les ``data fixtures``.
Données factices
-------------
@@ -440,7 +438,7 @@ Maintenant, mettez à jour les vendors pour que les changements soient pris en c
$ php bin/vendors install
-Cela va télécharger les dernières versions disponible si Github de chacun des bundles, et les installer au bon endroit.
+Cela va télécharger les dernières versions disponible sur Github de chacun des bundles, et les installer au bon endroit.
.. note::
@@ -451,7 +449,7 @@ Cela va télécharger les dernières versions disponible si Github de chacun des
Pour le DoctrineFixturesBundle: `Téléchargez <https://github.com/symfony/DoctrineFixturesBundle>`_ la version actuelle disponible sur Github, et décompressez son contenu dans ``vendor/bundles/Symfony/Bundle/DoctrineFixturesBundle``.
Mettez ensuite à jour le fichier ``app/autoloader.php`` pour enregistrer les nouveaux espaces de noms.
-Comme les sont également dans l'espace de nom ``Doctrine\Common``, ils doivent être placé avant la directive ``Doctrine\Common`` déjà existante, puisqu'elle précisent un nouveau chemin. Les espaces de noms sont vérifiés de haut en bas, donc les espaces de noms les plus spécifiques doivent être enregistrés avant ceux qui le sont moins.
+Comme les ``DataFixtures`` sont également dans l'espace de nom ``Doctrine\Common``, ils doivent être placé avant la directive ``Doctrine\Common`` déjà existante, puisqu'elle précisent un nouveau chemin. Les espaces de noms sont vérifiés de haut en bas, donc les espaces de noms les plus précis doivent être enregistrés avant ceux qui le sont moins.
.. code-block:: php
@@ -482,7 +480,7 @@ Maintenant enregistrons le ``DoctrineFixturesBundle`` dans le noyeau situé dans
Articles factices
~~~~~~~~~~~~~~~~~
-Nous sommes maintenant prêts à définir du contenu factice pour nos articles. Créez un fichier de fixtures dans ``src/Blogger/BlogBundle/DataFixtures/ORM/BlogFixtures.php`` et ajoutez-y le contenu suivant :
+Nous sommes maintenant prêts à définir du contenu factice pour nos articles. Créez un fichier de ``fixtures`` dans ``src/Blogger/BlogBundle/DataFixtures/ORM/BlogFixtures.php`` et ajoutez-y le contenu suivant :
.. code-block:: php
@@ -553,7 +551,7 @@ Nous sommes maintenant prêts à définir du contenu factice pour nos articles.
}
-Ce fichier contient un certain nombre de choses importantes à savoir lorsque l'on utilise Doctrine 2, en particulier sur comment faire persister les entités dans la base de donnée.
+Ce fichier contient un certain nombre de choses importantes à savoir lorsque l'on utilise Doctrine 2, en particulier sur comment faire persister les entités dans la base de données.
Regardons comment on crée un article :
@@ -572,11 +570,7 @@ Regardons comment on crée un article :
$manager->flush();
-On commence par créer une instance de la classe ``Blog``, et spécifie les valeurs pour ses attributs. A cet instant, Doctrine 2 ne connait rien de l'objet ``Entity``. C'est seulement lorsque l'on appelle ``$manager->persist($blog1)`` que l'on informe Doctrine 2 qu'il doit commencer à s'occuper des objets entité. L'objet ``$manager`` est ici une instance de ``EntityManager`` que nous avons vu plus tôt, lorsque nous allons chercher dans objets dans la base de donnée. Il est important de noter que bien que Doctrine 2 soit désormais conscient de l'objet entité, cet objet n'est toujours pas persisté dans la base de donnée, un appel à ``$manager->flush()`` est nécessaire pour cela. La méthode flush oblige Doctrine 2 à intéragir avec la base de donnée pour toute les entités dont il s'occupe. Par souci de performances, il est nécessaire de regrouper les appels Doctrine 2 et réaliser un unique flush, c'est comme ça que nous avons fait avec nos données factices. On crée chaque entité, dit à Doctrine 2 qu'il en a la charge, et finalement sauvegarde toutes les entités en une fois à la fin via ``flush``.
-
-.. tip:
-
- Vous avez peut-être remarqué que les affectations des attributs ``created`` et ``updated``. Ce n'est absolument pas la meilleure manière de saisir ces champs, car ils devraient être définis automatiquement lorsqu'un objet est créé ou mis à jour. Doctrine 2 nous propose une manière de réaliser cela que nous allons rapidement aborder.
+On commence par créer une instance de la classe ``Blog``, et spécifie les valeurs pour ses attributs. A cet instant, Doctrine 2 ne connait rien de l'objet ``Entity``. C'est seulement lors de l'appel de ``$manager->persist($blog1)`` que Doctrine 2 prend en charge les objets entité. L'objet ``$manager`` est ici une instance de ``EntityManager`` que nous avons vu plus tôt, lorsque nous allons chercher des objets entité dans la base de données. Il est important de noter que bien que Doctrine 2 soit désormais en charge de l'objet entité, cet objet n'est toujours pas persisté dans la base de donnée. Un appel à la méthode ``$manager->flush()`` est nécessaire pour cela. La méthode flush oblige Doctrine 2 à intéragir avec la base de donnée pour toute les entités dont il s'occupe. Par souci de performance, il est nécessaire de regrouper les appels Doctrine 2 et réaliser un unique flush, c'est comme ça que nous avons fait avec nos données factices. On crée chaque entité, on dit à Doctrine 2 qu'il en a la charge, et finalement on sauvegarde toutes les entités en une fois à la fin via ``flush``.
Charger les données factices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -595,20 +589,20 @@ Si vous regardez la page ``http://symblog.dev/app_dev.php/1``, vous devriez main
Essayez de changer la valeur du paramètre ``id`` dans l'URL pour la valeur 2. Vous devriez alors voir l'article suivant.
-Si toutefois vous vous rendez à l'adresse ``http://symblog.dev/app_dev.php/100`` vous devriez avoir une erreur 404, car il n'existe pas d'entité ayant pour id la valeur 100. Maintenant, essayez l'URL ``http://symblog.dev/app_dev.php/symfony2-blog``. Pourquoi n'avons nous pas droit à une erreur 404 ? Car l'action show n'est jamais executée. L'url n'arrive pas à faire correspondre cette adresse à une règle de routage (à cause de la nécessité pour l'identifiant des articles d'être un entier), c'est pourquoi on a a la place une exception qui dit qu'il n'existe pas de route pour cette adresse: ``No route found for "GET /symfony2-blog"`` exception.
+Si toutefois vous vous rendez à l'adresse ``http://symblog.dev/app_dev.php/100`` vous devriez avoir une erreur 404, car il n'existe pas d'entité ayant pour id la valeur 100. Maintenant, essayez l'URL ``http://symblog.dev/app_dev.php/symfony2-blog``. Pourquoi n'avons nous pas droit à une erreur 404 ? Car l'action show n'est jamais executée. L'url n'arrive pas à faire correspondre cette adresse à une règle de routage (à cause de la nécessité pour l'identifiant des articles d'être un entier), c'est pourquoi on a à la place une exception qui dit: il n'existe pas de route pour cette adresse - ``No route found for "GET /symfony2-blog"``.
Les Timestamps
--------------
Le terme le plus proche de Timestamp en français étant l'infame ``Horodatage``, je vais continuer d'utiliser le terme Timestamp. En gros, un timestamp, c'est un attribut qui sert à stocker une information sur une date. Pour finir ce chapitre, nous allons regarder les 2 timestamps de l'entité ``Blog``; ``created`` et ``updated``. Les fonctionnalités de ces 2 attributs sont communément définies comme ``Timestampable``. Promis, je vais quand même continuer de faire un effort pour les traductions, mais ne m'obligez pas à dire ``horodatables``.
-Ces attributs stockent les informations sur quand l'article a été créé, puis mis à jour pour la dernière fois. Comme nous ne souhaitons pas mettre à jour ce champ manuellement à chaque création ou mise à jour d'article, nous allons nous reposer sur Doctrine.
+Ces attributs stockent les informations sur la date et l'heure auxquelles un article a été créé, puis mis à jour pour la dernière fois. Comme nous ne souhaitons pas mettre à jour ce champ manuellement à chaque création ou mise à jour d'article, nous allons nous reposer sur Doctrine.
Doctrine 2 propose un
`système d'évènements <http://www.doctrine-project.org/docs/orm/2.0/en/reference/events.html>`_
-qui fournit un
+qui fournit
`des callback de cycle de vie <http://www.doctrine-project.org/docs/orm/2.0/en/reference/events.html#lifecycle-callbacks>`_.
-On peut utiliser ces callback pour préciser que nos entités doivent être averties de certains évènements. Il est par exemple possible d'être prévenu avant la mise à jour d'une entité, après une sauvegarde ou avant la suppression d'une entité. Afin d'utiliser ces callback, il est nécessaire d'enregistrer les entités pour cela, ce que l'on fait dans les métadonnées. Mettez à jour l'entité ``Blog`` dans ``src/Blogger/BlogBundle/Entity/Blog.php`` avec le contenu suivant :
+On peut utiliser ces callback pour préciser que nos entités doivent être averties de certains évènements. Il est par exemple possible d'être prévenu avant la mise à jour d'une entité, après une sauvegarde ou avant la suppression d'une entité. Afin d'utiliser ces callback, il est nécessaire de marquer les entités, ce que l'on fait dans les métadonnées. Mettez à jour l'entité ``Blog`` dans ``src/Blogger/BlogBundle/Entity/Blog.php`` avec le contenu suivant :
.. code-block:: php
@@ -668,11 +662,11 @@ On enregistre l'entité ``Blog`` afin d'être notifié de l'évènement ``preUpd
Comme les attributs timestampables sont un besoin récurrent dans les entités, un bundle est apparu pour ajouter son support. Il s'agit du `StofDoctrineExtensionsBundle <https://github.com/stof/StofDoctrineExtensionsBundle>`_, qui fournit plusieurs extensions pour Doctrine 2 intéressante comme Timestampable, Sluggable, and Sortable (triable).
- Nous verrons comment intégrer ce bundle plus loin dans le tutorial. Les plus pressés peuvent déjà regarder la page du `cookbook <http://symfony.com/doc/current/cookbook/doctrine/common_extensions.html>`_ à ce sujet.
+ Nous verrons comment intégrer ce bundle plus loin dans le tutoriel. Les plus pressés peuvent déjà regarder la page du `cookbook <http://symfony.com/doc/current/cookbook/doctrine/common_extensions.html>`_ à ce sujet.
Conclusion
----------
Nous avons couvert un certain nombre de concepts qui traitent du Modèle avec Doctrine 2. Nous avons également regardé comment générer des données factices, qui propose une solution simple pour avoir des données de test pour la période de développement et de test.
-La prochaine fois, nous regarderons comment étendre le modèle pour y ajouter le support des commentaires. Nous allons également commencer à construire la page d'accueil, et construire un dépot personnalisé pour cela. Nous parlerons également des migrations avec Doctrine, ainsi que des intéractions entre les formulaires et cette librairie pour permettre l'ajout de commentaires aux articles.
+La prochaine fois, nous regarderons comment étendre le modèle pour y ajouter le support des commentaires. Nous allons également commencer à construire la page d'accueil, et construire un dépôt personnalisé pour cela. Nous parlerons également des migrations avec Doctrine, ainsi que des intéractions entre les formulaires et cette librairie pour permettre l'ajout de commentaires aux articles.
View
117 docs/validateurs-et-formulaires.rst
@@ -18,7 +18,7 @@ La page de contact
Routage
~~~~~~~
-Comme avec la page ``A propos`` que nous avons crée dans le chapitre précédent, nous allons commencer par définir la route vers la page de contact. Ouvrez le fichier de routage du ``BloggerBlogBundle`` situé dans
+Comme avec la page ``A propos`` que nous avons créée dans le chapitre précédent, nous allons commencer par définir la route vers la page de contact. Ouvrez le fichier de routage du ``BloggerBlogBundle`` situé dans
``src/Blogger/BlogBundle/Resources/config/routing.yml`` et ajoutez-y la règle de routage suivante :
.. code-block:: yaml
@@ -31,12 +31,12 @@ Comme avec la page ``A propos`` que nous avons crée dans le chapitre précéden
_method: GET
-Il n'y a rien de nouveau ici, la règle associe le lien ``/contact``pour la méthode HTTP ``GET`` et exécute l'action ``contact`` du controlleur ``Page`` dans le ``BloggerBlogBundle``.
+Il n'y a rien de nouveau ici, la règle associe le lien ``/contact``pour la méthode HTTP ``GET`` et exécute l'action ``contact`` du contrôleur ``Page`` dans le ``BloggerBlogBundle``.
-Controlleur
-~~~~~~~~~~~
+Contrôleur
+~~~~~~~~~~
-Ensuite, ajoutons l'action pour la page de contact dans le controlleur ``Page`` du ``BloggerBlogBundle`` situé dans ``src/Blogger/BlogBundle/Controller/PageController.php``.
+Ensuite, ajoutons l'action pour la page de contact dans le contrôleur ``Page`` du ``BloggerBlogBundle`` situé dans ``src/Blogger/BlogBundle/Controller/PageController.php``.
.. code-block:: php
@@ -48,7 +48,7 @@ Ensuite, ajoutons l'action pour la page de contact dans le controlleur ``Page``
}
// ..
-Pour le moment cette action est très simple, elle affiche simplement la vue de la page de contact. Nous reviendrons sur ce controlleur plus tard.
+Pour le moment cette action est très simple, elle affiche simplement la vue de la page de contact. Nous reviendrons sur ce contrôleur plus tard.
Vue
~~~
@@ -91,7 +91,7 @@ Finalement nous devons mettre à jour le lien dans le template de l'application,
</nav>
{% endblock %}
-Si vous vous rendez avec votre navigateur à l'adresse ``http://symblog.dev/app_dev.php/`` et cliquez sur le lien vers la page de contact dans la barre de navigation, vous devriez voir une page de contact très simple. Maintenant que la page est correctement mise en place, il est temps de commencer à travailler sur le formulaire de contact. C'est découpé en 2 parties distinctes: le validateur et le formulaire. Avant de parler de ces deux sujets, il faut réfléchir à commencer nous allons gérer les données du formulaire de contact.
+Si vous vous rendez avec votre navigateur à l'adresse ``http://symblog.dev/app_dev.php/`` et cliquez sur le lien vers la page de contact dans la barre de navigation, vous devriez voir une page de contact très simple. Maintenant que la page est correctement mise en place, il est temps de commencer à travailler sur le formulaire de contact. C'est découpé en 2 parties distinctes: le validateur et le formulaire. Avant de parler de ces deux sujets, il faut réfléchir à la manière dont nous allons gérer les données du formulaire de contact.
L'entité Contact
----------------
@@ -160,7 +160,7 @@ Comme vous pouvez le voir cette classe définit simplement quelques membres prot
.. note::
- Faisons une petite digression pour parler de l'utilisation des espaces de nom dans Symfony2. La classe d'entité que nous avons créé définit pour espace de nom ``Blogger\BlogBundle\Entity``. Comme le chargement automatique de Symfony2 supporte le `standard PSR-0 <http://groups.google.com/group/php-standards/web/psr-0-final-proposal?pli=1>`_, l'espace de nom reflète directement la structure de répertoires du bundle. La classe d'entité ``Enquiry`` est située dans ``src/Blogger/BlogBundle/Entity/Enquiry.php``, ce qui permet à Symfony2 de pouvoir correctement charger automatiquement cette classe.
+ Faisons une petite digression pour parler de l'utilisation des espaces de nom dans Symfony2. La classe d'entité que nous avons créée est définie par l'espace de nom ``Blogger\BlogBundle\Entity``. Comme le chargement automatique de Symfony2 supporte le `standard PSR-0 <http://groups.google.com/group/php-standards/web/psr-0-final-proposal?pli=1>`_, l'espace de nom reflète directement la structure de répertoires du bundle. La classe d'entité ``Enquiry`` est située dans ``src/Blogger/BlogBundle/Entity/Enquiry.php``, ce qui permet à Symfony2 de charger cette classe automatiquement de manière correcte.
Comment le chargeur automatique de Symfony2 sait que l'espace de nom ``Blogger`` se trouve dans le répertoire ``src`` ?
C'est grâce à la configuration du chargement automatique dans ``app/autoloader.php``
@@ -174,12 +174,12 @@ Comme vous pouvez le voir cette classe définit simplement quelques membres prot
Cette ligne de code enregistre les répertoires à utiliser pour tous les espaces de noms qui ne sont pas enregistrés. Comme l'espace de nom ``Blogger`` n'est pas enregistré, le chargement automatique des classes de Symfony2 va chercher les fichiers requis dans le répertoire ``src``
- Le chargement automatique et les espaces de nom sont des concepts très puissant dans Symfony2. Si vous avez des problèmes dans lesquels PHP n'arrivent pas à trouver une ou plusieurs classes, il y a des chances pour qu'il y ait des erreurs dans votre espace de nom ou dans votre structure de répertoires. Vérifiez également que les espaces de nom soient bien enregistrés dans le chargeur comme vu au dessus. Vous ne devriez pas être tentés de ``réparer`` celà en utilisant les directives PHP ``require`` ou ``include``.
+ Le chargement automatique et les espaces de nom sont des concepts très puissant dans Symfony2. Si vous avez des problèmes dans lesquels PHP n'arrivent pas à trouver une ou plusieurs classes, il y a des chances pour qu'il y ait des erreurs dans votre espace de nom ou dans votre structure de répertoires. Vérifiez également que les espaces de nom soient bien enregistrés dans le chargeur comme vu au dessus. Vous ne devriez jamais être tentés de ``réparer`` celà en utilisant les directives PHP ``require`` ou ``include``.
Formulaires
-----------
-Ensuite, nous allons créer le formulaire. Symfony2 est livré avec une librairie de formulaires très puissante qui rend très facile le fait de travailler avec les formulaires. Comme avec tous les autres composants de Symfony2, le composant de formulaire peut être utilisé à l'extérieur de Symfony2 pour vos propores projets. La `source du composant de formulaire <https://github.com/symfony/Form>`_ est disponible sur Github. Nous allons commencer par créer une classe ``AbstractType`` qui représente le formulaire de requêtes. Nous aurions pu créer le formulaire directement dans le controlleur et ne pas nous embeter avec cette classe, néanmoins séparer le formulaire dans sa propre classe nous permet de réutiliser le formulaire dans l'application. Cela nous évite également d'encombrer le controller, car après tout, il est censé être simple : son but est de faire le lien entre le modèle et la vue.
+Ensuite, nous allons créer le formulaire. Symfony2 est livré avec une librairie de formulaires très puissante qui rend très facile le fait de travailler avec les formulaires. Comme avec tous les autres composants de Symfony2, le composant de formulaire peut être utilisé à l'extérieur de Symfony2 pour vos propores projets. La `source du composant de formulaire <https://github.com/symfony/Form>`_ est disponible sur Github. Nous allons commencer par créer une classe ``AbstractType`` qui représente le formulaire de contact. Nous aurions pu créer le formulaire directement dans le contrôleur et ne pas nous embêter avec cette classe, néanmoins séparer le formulaire dans sa propre classe nous permet de réutiliser le formulaire dans l'application. Cela nous évite également d'encombrer le contrôleur, car après tout, il est censé être simple : son but est de faire le lien entre le modèle et la vue.
EnquiryType
~~~~~~~~~~~
@@ -213,14 +213,14 @@ Créez un nouveau fichier dans ``src/Blogger/BlogBundle/Form/EnquiryType.php`` e
}
La classe ``EnquiryType`` nous permet de présenter la classe ``FormBuilder``. la classe ``FormBuilder`` est votre meilleur atout lorsqu'il est question de créer des formulaires.
-Elle est capable de simplifier le processus de définition des champs à partir des métadonnées qu'un champ possède. Comme notre entité est très simple, nous n'avons défini aucune métadonnée donc le ``FormBuilder`` va créer par défaut des champs de texte. C'est adapté à la plupart des champs, sauf pour le corps du message pour lequel nous souhaitons utiliser une ``textarea``, et pour l'adresse email pour laquelle nous allons utiliser le nouveau champ d'adresse email proposé par l'HTML5.
+Elle est capable de simplifier le processus de définition des champs à partir des métadonnées qu'un champ possède. Comme notre entité est très simple, nous n'avons défini aucune métadonnée, donc le ``FormBuilder`` va créer des champs de texte par défaut. C'est adapté à la plupart des champs, sauf pour le corps du message pour lequel nous souhaitons utiliser une ``textarea``, et pour l'adresse email pour laquelle nous allons utiliser le nouveau champ d'adresse email proposé par l'HTML5.
.. note::
Un aspect clé à prendre en compte est le fait que la méthode ``getName`` doit renvoyer un identifiant unique.
-Créer le formulaire dans le controlleur
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Créer le formulaire dans le contrôleur
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nous avons désormais défini l'entité ``Enquiry`` et la classe ``EnquiryType``, nous pouvons désormais mettre à jour l'action pour la page de contact afin de s'en servir. Remplacez le contenu de la méthode contactAction dans le fichier ``src/Blogger/BlogBundle/Controller/PageController.php`` par le suivant :
@@ -250,15 +250,15 @@ Nous avons désormais défini l'entité ``Enquiry`` et la classe ``EnquiryType``
));
}
-Nous commençons par créer une instance de l'entité ``Enquiry``. Cette entité représent les données d'un message sur la page de contact. Nous créons ensuite le formulaire correspondant: nous spécifions le type ``EnquiryType`` créé précedemment, et passons en paramètres notre object entité $enquiry. La méthode ``createForm`` est capable d'utiliser ces 2 patrons pour créer la représentation d'un formulaire.
+Nous commençons par créer une instance de l'entité ``Enquiry``. Cette entité représente les données d'un message sur la page de contact. Nous créons ensuite le formulaire correspondant: nous spécifions le type ``EnquiryType`` créé précédemment, et passons en paramètres notre object entité $enquiry. La méthode ``createForm`` est capable d'utiliser ces 2 patrons pour créer la représentation d'un formulaire.
-Comme cette action du controlleur va maintenant s'occuper d'afficher et traiter le formulaire qui lui est soumis, nous devons faire attention à la méthode HTTP utilisée. Les formulaires soumis sont générallement envoyés via la méthode ``POST``, et notre formulaire n'y fera pas exception. Si la méthode de requête est de type ``POST``, un appel à la méthode ``bindRequest`` va retransformer les données soumises vers notre objet ``$enquiry``. A ce moment-là, notre objet ``$enquiry`` contiendra une représentation de ce que l'utilisateur aura envoyé.
+Comme cette action du contrôleur va maintenant s'occuper d'afficher et traiter le formulaire qui lui est soumis, nous devons faire attention à la méthode HTTP utilisée. Les formulaires soumis sont généralement envoyés via la méthode ``POST``, et notre formulaire n'y fera pas exception. Si la requête est de type ``POST``, un appel à la méthode ``bindRequest`` va transformer les données soumises pour les associées à notre objet ``$enquiry``. A ce moment-là, l'objet ``$enquiry`` contiendra une représentation de ce que l'utilisateur aura envoyé.
Nous vérifions ensuite que le formulaire est valide. Comme nous n'avons pas précisé de validateurs pour le moment, le formulaire sera toujours valide.
Enfin, nous précisons le template à utiliser pour l'affichage. Notez que nous passons également à la vue une représentation du formulaire à afficher, ce qui nous permet d'effectuer l'affichage adéquat dans la vue.
-Comme nous avons utilisé 2 nouvelles classes dans notre controlleur, nous devons importer les espaces de nom correspondants. Mettez à jour le début du fichier ``src/Blogger/BlogBundle/Controller/PageController.php`` avec le contenu suivant.
+Comme nous avons utilisé 2 nouvelles classes dans notre contrôleur, nous devons importer les espaces de nom correspondants. Mettez à jour le début du fichier ``src/Blogger/BlogBundle/Controller/PageController.php`` avec le contenu suivant.
.. code-block:: php
@@ -290,9 +290,9 @@ Afin de démontrer la puissance des méthodes de Twig, nous allons utiliser le b
<input type="submit" />
</form>
-Bien que c'est très utile et simple durant la phase de prototypage, cela s'avère très limité lorsque le besoin de personnalisation est important, ce qui est souvent le cas avec les formulaires.
+Bien que cette méthode soit utile et très simple durant la phase de prototypage, cela s'avère limité lorsque le besoin de personnalisation est important, ce qui est souvent le cas avec les formulaires.
-Pour notre formulaire de contacts, nous allons trouver opter pour un compromis. Remplacez le code du template ``src/Blogger/BlogBundle/Resources/views/Page/contact.html.twig`` par le suivant :
+Pour notre formulaire de contacts, nous allons opter pour un compromis. Remplacez le code du template ``src/Blogger/BlogBundle/Resources/views/Page/contact.html.twig`` par le suivant :
.. code-block:: html
@@ -324,25 +324,25 @@ Pour notre formulaire de contacts, nous allons trouver opter pour un compromis.
Comme vous pouvez le voir, nous utilisons 4 nouvelles fonctions Twig pour afficher notre formulaire.
-La première fonction ``form_enctype`` définit le type de contenu du formulaire. C'est nécessaire lorsqu'un formulaire traite avec des fichiers uploadés. Ce n'est donc pas nécessaire pour le moment, mais c'est une bonne habitude que de l'utiliser pour tous les formulaires au cas où l'upload de fichiers soit ajouté dans le futur. Débugguer un formulaire qui traite de l'upload de fichier dans lequel le type de contenu n'est pas spécifié peut être un vrai casse tête !
+La première fonction ``form_enctype`` définit le type de contenu du formulaire. C'est nécessaire lorsqu'un formulaire traite avec des fichiers uploadés. Ce n'est donc pas nécessaire pour le moment, mais c'est une bonne habitude que de l'utiliser pour tous les formulaires au cas où l'upload de fichier soit ajouté dans le futur. Déboguer un formulaire qui traite de l'upload de fichier dans lequel le type de contenu n'est pas spécifié peut être un vrai casse tête !
-La seconde fonction ``form_errors`` va afficher les erreurs du formulaires si jamais la validation échoie.
+La seconde fonction ``form_errors`` affichera les erreurs du formulaire dans le cas où la validation échoie.
-La 3ème fonction ``form_row`` affiche un élément lié à un des champs. Cela inclue les erreurs pour ce champ, l'étiquette liée au champ ainsi que l'objet du formulaire à afficher.
+La 3ème fonction ``form_row`` affiche les éléments liés à un champ. Cela comporte toutes les erreurs associées au champ, l'étiquette liée au champ ainsi que l'élément du champ de formulaire lui même.
-Enfin, nous utilisons la fonction ``form_rest``. C'est toujours une bonne habitude d'utiliser cette fonction à la fin de l'affichage pour afficher les champs qui auraient pû être oubliés, ce qui inclue les champs cachés ainsi que la clé CSRF de Symfony2.
+Enfin, nous utilisons la fonction ``form_rest``. C'est toujours une bonne habitude d'utiliser cette fonction à la fin de l'affichage pour afficher les champs qui auraient pû être oubliés, ce qui inclue les champs cachés ainsi que le jeton CSRF de Symfony2.
.. note::
- Les attaques de type Cross-site request forgery (CSRF) sont expliquées en détails dans le
- `chapitre sur les formulaire <http://symfony.com/doc/current/book/forms.html#csrf-protection>`_
+ Les attaques de type Cross-site request forgery (CSRF) sont expliquées en détail dans le
+ `chapitre sur les formulaires <http://symfony.com/doc/current/book/forms.html#csrf-protection>`_
du livre Symfony2.
Donner du style au formulaire.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Si vous regardez maintenant notre formulaire via la page ``http://symblog.dev/app_dev.php/contact``, vous devriez remarquer qu'il n'est pas très engageant. Ajoutons lui du style pour améliorer son rendu. Comme les styles sont spécifiques à notre bundle de blog, nous allons les créer dans une feuille de style à l'intérieur même du bundle. Créez un nouveau fichier dans ``src/Blogger/BlogBundle/Resources/public/css/blog.css`` et copiez-y le contenu suivant :
+Si vous regardez maintenant notre formulaire via la page ``http://symblog.dev/app_dev.php/contact``, vous remarquerez qu'il n'est pas très engageant. Ajoutons lui du style pour améliorer son rendu. Comme les styles sont spécifiques à notre bundle de blog, nous allons les créer dans une feuille de style à l'intérieur même du bundle. Créez un nouveau fichier dans ``src/Blogger/BlogBundle/Resources/public/css/blog.css`` et copiez-y le contenu suivant :
.. code-block:: css
@@ -357,7 +357,7 @@ Si vous regardez maintenant notre formulaire via la page ``http://symblog.dev/ap
form.blogger input[type="submit"] { margin-left: 110px; width: 508px; line-height: 26px; font-size: 20px; min-height: 26px; }
form.blogger ul li { color: #ff0000; margin-bottom: 5px; }
-Nous devons faire savoir à l'application que nous souhaitons utiliser cette feuille de style. Nous pourrions importer la feuille de style dans le template de la page de contact, mais comme d'autres templates pourraient utiliser cette feuille de style par la suite, cela a plus de sens de l'importer dans le ``layout`` que nous avons créé pour notre ``BloggerBlogBundle`` dans le chapitre 1. Ouvrez ce fichier,
+Nous devons informer l'application que nous souhaitons utiliser cette feuille de style. Nous pourrions importer la feuille de style dans le template de la page de contact, mais comme d'autres templates pourraient utiliser cette feuille de style par la suite, cela a plus de sens de l'importer dans le ``layout`` que nous avons créé pour notre ``BloggerBlogBundle`` du chapitre 1. Ouvrez ce fichier,
situé dans ``src/Blogger/BlogBundle/Resources/views/layout.html.twig`` et mettez-y le contenu suivant :
.. code-block:: html
@@ -374,7 +374,7 @@ situé dans ``src/Blogger/BlogBundle/Resources/views/layout.html.twig`` et mette
Sidebar content
{% endblock %}
-Vous pouvez voir que nous avons défini un bloc pour les styles qui remplace le bloc précédemment défini dans le template parent. Il est néanmoin important de remarquer l'appel à la fonction ``parent``. Cette fonction s'occupe d'importer le contenu du bloc du template parent ``app/Resources/base.html.twig``, dans le cas présent celui s'occupant des feuilles de style, ce qui nous permet d'ajouter nos nouvelles feuilles de style, car nous ne voulons pas supprimer celles qui auraient pû déjà être nécessaires.
+Remarquez que nous avons défini un bloc ``stylesheets`` qui remplace le bloc défini dans le template parent. Il est important de remarquer l'appel à la fonction ``parent``. Cette fonction se charge d'importer le contenu du bloc dans le template parent ``app/Resources/base.html.twig``, dans le cas présent celui s'occupant des feuilles de style, cela nous permet d'ajouter nos nouvelles feuilles de style à la suite. Nous ne voulons pas supprimer les feuilles de style existantes.
Afin que la fonction ``asset`` fasse les bons liens avec les ressources, nous devons copier ou déplacer les ressources du bundle dans le répertoire ``web`` de l'application. Cela peut être fait par la commande suivante:
@@ -390,9 +390,9 @@ Afin que la fonction ``asset`` fasse les bons liens avec les ressources, nous de
php app/console assets:install web
- Cette méthode va en fait copier les ressources présentes dans le répertoire ``public`` des bundles dans le répertoire ``web`` de l'application. Comme les fichiers sont copiés, il est nécessaire de lancer cette cmmande à chaque fois que vous faites une modification dans les ressources publiques utilisées par un bundle.
+ Cette méthode va en fait copier les ressources présentes dans le répertoire ``public`` des bundles dans le répertoire ``web`` de l'application. Comme les fichiers sont copiés, il est nécessaire de lancer cette commande à chaque fois que vous faites une modification dans les ressources publiques utilisées par un bundle.
-Vous pouvez maintenant rafraichir la page de contact, dans laquelle le nouveau style s'applique au formulaire. C'est quand même un peu plus sympa comme ça non ?
+Vous pouvez maintenant rafraîchir la page de contact, dans laquelle le nouveau style s'applique au formulaire. C'est quand même un peu plus sympa comme ça non ?
.. image:: ../_static/images/part_2/contact.jpg
:align: center
@@ -400,8 +400,7 @@ Vous pouvez maintenant rafraichir la page de contact, dans laquelle le nouveau s
.. tip::
- Alors que la fonction ``asset`` nous permet d'utiliser les ressources, il y a une meilleure alternative pour cette opération, il s'agit .
- `d'Assectic <https://github.com/kriswallsmith/assetic>`_. Cette librairie, écrite par `Kris Wallsmith <https://github.com/kriswallsmith>`_ est fournie par défaut avec la distribution standard de Symfony2. Cette librairie permet une gestion des ressources bien meilleure que celle que propose Symfony2. Assetic permet de lancer des filtres sur les fichiers pour automatiquement combiner ou compresser les fichiers. Elle permet également de lancer des filtres sut les images. Assetic nous permet également de faire référence à des ressources directement à l'intérieur des répertoires publics des bundles, sans avoir à lancer la commande ``assets:install``. Nous reviendrons plus en détail sur ce sujet dans un chapitre ultérieur.
+ Alors que la fonction ``asset`` nous permet d'utiliser les ressources, il y a une meilleure alternative pour cette opération, il s'agit `d'Assectic <https://github.com/kriswallsmith/assetic>`_. Cette librairie, écrite par `Kris Wallsmith <https://github.com/kriswallsmith>`_ est fournie par défaut avec la distribution standard de Symfony2. Elle permet une gestion des ressources bien meilleure que celle proposée par Symfony2. Assetic permet de lancer des filtres sur les fichiers pour les fusionner automatiquement, les alléger ou les compresser. Elle permet également de lancer des filtres de compression sur les images. Enfin Assetic nous permet de faire référence à des ressources directement à l'intérieur des répertoires publics des bundles, sans avoir à lancer la commande ``assets:install``. Nous reviendrons plus en détail sur ce sujet dans un chapitre ultérieur.
Echec à la soumission
---------------------
@@ -412,7 +411,7 @@ Les plus enthousiastes parmi vous auront probablement déjà essayé de soumettr
:align: center
:alt: No route found for "POST /contact": Method Not Allowed (Allow: GET, HEAD)
-Cette erreur nous dit qu'il n'y a pas de route qui corresponde à l'adresse ``/contact`` pour la méthode HTTP POST. La route que nous avons déjà définie n'accepte que les requêtes de type GET et HEAD, car nous l'avons configurée comme cela.
+Ce message d'erreur nous indique qu'il n'y a pas de route correspondante à l'adresse ``/contact`` pour la méthode HTTP POST. La route que nous avons définie n'accepte que les requêtes de type GET et HEAD, car nous l'avons configurée comme cela.
Mettons à jour notre route de contact dans ``src/Blogger/BlogBundle/Resources/config/routing.yml`` afin de permettre également les requêtes de type POST.
@@ -427,16 +426,16 @@ Mettons à jour notre route de contact dans ``src/Blogger/BlogBundle/Resources/c
.. tip::
- Vous vous demandez probablement pourquoi la route acceptait les requêtes de type HEAD, alors que seul HEAD avait été précisé: c'est car une requête HEAD est une requete GET où seul le header HTTP est renvoyé.
+ Vous vous demandez probablement pourquoi la route acceptait les requêtes de type HEAD, alors que seul GET avait été spécifié. Et bien parce qu'une requête HEAD est de type GET où seules les en-têtes HTTP sont retournées.
-Maintenant vous pouvez soumettre le formulaire qui devrait fonctionner comme espéré, bien qu'il ne fasse rien de particulier pour le moment. La page redirige simplement à nouveau vers le formulaire de contact.
+Maintenant vous pouvez soumettre le formulaire qui devrait fonctionner comme attendu, bien qu'il ne fasse rien de particulier pour le moment. La page redirige simplement à nouveau vers le formulaire de contact.
Validateurs.
------------
-Les validateurs de Symfony2 permettent de valider les données. La validation est une tâche courante lorsqu'il est question de valider les données de formulaire, qui doit également être réalisée avant que les données ne soient envoyées dans une base de données. Les validateurs Symfony2 nous permettent de séparer notre logique de validation des composants qui pourraient s'en servir, tels que le composant de formulaire ou de base de donnée. Cette approche signifie que nous allons avoir un jeu de règles de validation par objet.
+Les validateurs de Symfony2 permettent de valider les données. La validation est une tâche courante lorsqu'il est question de valider les données de formulaire. Cette tâche doit être réalisée avant que les données ne soient envoyées vers une base de données. Les validateurs Symfony2 nous permettent de séparer notre logique de validation des composants qui pourraient s'en servir, tels que les composants de formulaire ou de base de donnée. Cette approche signifie que nous allons avoir un jeu de règles de validation par objet.
-Commençons par mettre à jour l'entité ``Enquiry`` dans ``src/Blogger/BlogBundle/Entity/Enquiry.php`` pour préciser quelques validateurs. N'oubliez pas d'ajouter les 5 nouveaux ``use`` au début du fichier.
+Commençons par mettre à jour l'entité ``Enquiry`` dans ``src/Blogger/BlogBundle/Entity/Enquiry.php`` pour spécifier quelques validateurs. N'oubliez pas d'ajouter les 5 nouvelles déclarations avec ``use`` au début du fichier.
.. code-block:: php
@@ -486,23 +485,23 @@ Vous pouvez maintenant soumettre le formulaire de contact, et les données soumi
.. tip::
- Si vous utilisez un navigateur qui supporte le HTML5 (il y a de grandes chances pour que ce soit le cas), des messages HTML5 vont apparaitre pour vous faire respecter certaines contraintes à partir des métadonnées de votre objet ``Entity``. Vous pouvez le voir pour l'élément email, dont le code dans l'HTML est le suivant :
+ Si vous utilisez un navigateur qui supporte le HTML5 (il y a de grandes chances pour que ce soit le cas), des messages HTML5 vont apparaître pour vous faire respecter certaines contraintes à partir des métadonnées de votre objet ``Entity``. Vous pouvez le voir pour l'élément email, dont le code HTML est le suivant :
.. code-block:: html
<input type="email" value="" required="required" name="contact[email]" id="contact_email">
- Il utilise un des nouveaux champs HTML5, et l'attribut ``required`` est défini. La validation côté client est bien dans le sens où elle ne nécessite pas un aller-retour avec le serveur pour valider le formulaire, néanmoins elle ne devrait pas être utilisée seule. Vous devriez toujours valider les données côté serveur, car il est très facile pour un utilisateur de passer outre la validation côté client.
+ Il utilise un des nouveaux champs HTML5, dont l'attribut ``required`` est défini. La validation côté client est bien dans le sens où elle ne nécessite pas un aller-retour avec le serveur pour valider le formulaire, néanmoins elle ne devrait pas être utilisée seule. Vous devriez toujours valider les données côté serveur, car il est très facile pour un utilisateur de passer outre la validation côté client.
Envoyer l'email
---------------
-Bien que notre formulaire nous permettre actuellement de soumettre des requêtes, rien ne leur arrive réellement pour le moment. Mettons à jour le controlleur afin d'envoyer un email au webmaster du blog. Symfony2 est livré avec la librairie d'envoi d'email `Swift Mailer <http://swiftmailer.org/>`_. Il s'agit d'une librairie très puissante, nous allons seulement effleurer la surface de ce qu'il est possible de faire avec.
+Bien que notre formulaire nous permettre actuellement de soumettre des requêtes, rien ne leur arrive réellement pour le moment. Mettons à jour le contrôleur afin d'envoyer un email au webmaster du blog. Symfony2 est livré avec la librairie d'envoi d'email `Swift Mailer <http://swiftmailer.org/>`_. Il s'agit d'une librairie très puissante, nous allons seulement effleurer la surface de ce qu'il est possible de faire avec.
Configurer les paramètres de Swift Mailer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Swift Mailer est déjà configuré de base dans la distribution standard de Symfony2, néanmoins nous devons configurer quelques paramètres concernant la méthode d'envoi, et lui fournir les accréditations nécessaires pour réaliser cette tâche. Ouvrez le fichier de paramètres dans ``app/parameters.ini`` et trouvez les paramètres préfixés par ``mailer_``.
+Swift Mailer est déjà configurée de base dans la distribution standard de Symfony2, néanmoins nous devons configurer quelques paramètres concernant la méthode d'envoi, et lui fournir les accréditations nécessaires pour réaliser cette tâche. Ouvrez le fichier de paramètres dans ``app/parameters.ini`` et trouvez les paramètres préfixés par ``mailer_``.
.. code-block:: text
@@ -524,14 +523,14 @@ Swift Mailer propose un certain nombre de méthodes pour envoyer les emails, ent
.. warning::
- Faites attention si vous utilisez un système de contrôle de version (SCV) tel que Git pour votre projet, en particulier si votre dépôt est accessible publiquement à n'importe qui. Vous devriez vous assurer que les fichiers qui contiennent des informations sensibles, tel que
+ Faites attention si vous utilisez un système de contrôle de version (SCV) tel que Git pour votre projet, en particulier si votre dépôt est accessible publiquement à n'importe qui. Vous devriez vous assurer que les fichiers contenant des informations sensibles, tel que
``app/parameters.ini``, sont dans la liste des fichier à ignorer. Une approche courante consiste à suffixer le nom de fichier qui a des informations sensibles, tel que ``app/parameters.ini``, avec ``.dist``.
- Vous pouvez alors proposer des valeurs par défaut pour les paramètres sensibles dans ce fichier, et l'ajouter à votre gestionnaire de version, pendant que le vrai fichier, par exemple ``app/parameters.ini`` est dans la liste de ceux à ignorer. Vous pouvez alors déployer les fichiers ``*.dist`` avec votre projet et permettre aux développeurs de supprimer l'extension .dist et remmplir les paramètres requis.
+ Vous pouvez alors proposer des valeurs par défaut pour les paramètres sensibles dans ce fichier, et l'ajouter à votre gestionnaire de version, pendant que le vrai fichier, par exemple ``app/parameters.ini`` est inclus dans la liste de ceux à ignorer. Vous pouvez alors déployer les fichiers ``*.dist`` avec votre projet et permettre aux développeurs de supprimer l'extension .dist et renseigner les paramètres requis.
-Mise à jour du controlleur.
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Mise à jour du contrôleur
+~~~~~~~~~~~~~~~~~~~~~~~~~
-Mettez à jour le controlleur de ``Page`` situé dans ``src/Blogger/BlogBundle/Controller/PageController.php`` avec le contenu suivant :
+Mettez à jour le contrôleur de ``Page`` situé dans ``src/Blogger/BlogBundle/Controller/PageController.php`` avec le contenu suivant :
.. code-block:: php
@@ -562,10 +561,10 @@ Une fois que la librairie Swift Mailer nous a permis de créer une instance d'un
.. note::
- Comme la librairie Swift Mailer n'utilise pas les espaces de noms, nous devons préfixer la classer avec avec un ``\``. Cela dit à PHP de réaliser l'échappement vers l' `espace global <http://www.php.net/manual/en/language.namespaces.global.php>`_.
- Vous devrez préfixer tous les classes et fonctions qui ne sont pas dans un espace de nom avec un ``\``. Si vous ne placiez pas préfixe avant la classe ``Swift_Message``, PHP chercherait alors la classe dans l'espace de nom actuel, dans cet exemple ``Blogger\BlogBundle\Controller``, amenant ainsi à l'apparition d'une erreur, car la classe ne peut légitimement être trouvée.
+ Comme la librairie Swift Mailer n'utilise pas les espaces de nom, nous devons préfixer la classe avec avec un ``\``. Cela indique à PHP de réaliser l'échappement vers l' `espace global <http://www.php.net/manual/en/language.namespaces.global.php>`_.
+ Vous devrez préfixer tous les classes et fonctions qui ne sont pas dans un espace de nom avec un ``\``. Si vous ne placiez pas préfixe avant la classe ``Swift_Message``, PHP chercherait alors la classe dans l'espace de nom actuel, dans cet exemple ``Blogger\BlogBundle\Controller``, conduisant à l'apparition d'une erreur, car la classe ne peut légitimement pas être trouvée.
-Nous avons également émis un message ``flash`` sur la session. Les messages flash sont des messages qui sont affichés seulement après une requête, après celà ils sont supprimés par Symfony2. Le message flash sera affiché dans le template actuel pour informer l'utilisateur que le message a été envoyé. Comme les messages flash sont seulement affichés pour une unique requête, ils sont parfaits pour notifier l'utilisateur de la réussite (ou l'échec) des actions précédentes.
+Nous avons également émis un message ``flash`` sur la session. Les messages flash sont des messages qui sont affichés seulement après une requête, ensuite ils sont supprimés par Symfony2. Le message flash sera affiché dans le template actuel pour informer l'utilisateur que le message a été envoyé. Comme les messages flash ne sont affichés qu'après une requête unique, ils sont parfaits pour notifier l'utilisateur de la réussite (ou l'échec) des actions précédentes.
Pour afficher les messages flash nous devons mettre à jour le template de la page de contact situé dans ``src/Blogger/BlogBundle/Resources/views/Page/contact.html.twig``. Mettez à jour le contenu du template avec ce qui suit :
@@ -589,12 +588,12 @@ Pour afficher les messages flash nous devons mettre à jour le template de la pa
{# rest of template ... #}
-Cela vérifie qu'il y a un message flash à afficher avec pour identificateur 'blogger-notice', et si c'est le cas l'affiche.
+Cela vérifie qu'il y a un message flash à afficher avec pour identificateur 'blogger-notice', et si c'est le cas on l'affiche.
Enregistrer l'email du webmaster
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Symfony2 propose un système de configuration que nous pouvons utiliser pour définir nos propres paramètres. Nous allons utiliser cette méthode afin de définir une adresse email pour le webmaster, plutôt que de la coder en dur dans le controlleur comme nous l'avons fait au dessus. De cette manière, nous pourrons facilement réutiliser cette variable à d'autres endroits sans dupliquer du code. De plus, lorsque votre blog aura généré tellement de traffic que les requêtes seront trop pénibles à gérer par le webmaster, il sera peut être temps de les déléguer à votre assistant. Créez un nouveau fichier dans ``src/Blogger/BlogBundle/Resources/config/config.yml`` et collez-y le code suivant :
+Symfony2 propose un système de configuration que nous pouvons utiliser pour définir nos propres paramètres. Nous allons utiliser cette méthode afin de définir une adresse email pour le webmaster, plutôt que de la coder en dur dans le contrôleur comme nous l'avons fait au dessus. De cette manière, nous pourrons facilement réutiliser cette variable à d'autres endroits sans dupliquer le code. De plus, lorsque votre blog aura généré tellement de traffic que les requêtes seront trop pénibles à gérer par le webmaster, il sera peut être temps de les déléguer à votre assistant. Créez un nouveau fichier dans ``src/Blogger/BlogBundle/Resources/config/config.yml`` et collez-y le code suivant :
.. code-block:: yaml
@@ -604,7 +603,7 @@ Symfony2 propose un système de configuration que nous pouvons utiliser pour dé
blogger_blog.emails.contact_email: contact@email.com
-Lorsque l'on définit des paramètres, c'est une bonne habitude de découper le nom de la variable en un certain nombre de composants. La première partie devrait être une version en minuscule du nom de bundle, en utilisant des underscore ``_`` pour séparer les mots. Dans cet exemple, nous avons remplacé ``BloggerBlogBundle`` en ``blogger_blog``. Le reste du nom de paramètres doit contenir n'importe quel nombre de parties, séparées par des caractères points ``.``, ce qui permet de grouper logiquement les paramètres.
+Lorsque l'on définit des paramètres, c'est une bonne habitude de découper le nom de la variable en un certain nombre de composants. La première partie devrait être le nom du bundle en minuscule, en utilisant des underscore ``_`` pour séparer les mots. Dans cet exemple, nous avons remplacé ``BloggerBlogBundle`` par ``blogger_blog``. Le reste du nom de paramètres peut contenir n'importe quel nombre de parties, séparées par des points ``.``. Cela nous permet de regrouper les paramètres logiquement.
Afin que l'application Symfony2 puisse utiliser ces nouveaux paramètres, nous devons importer le nouveau fichier de configuration situé dans ``app/config/config.yml``. Pour réaliser cela, mettez à jour les ``imports`` au début du fichier par ce qui suit :
@@ -656,7 +655,7 @@ Nous pouvons enfin mettre à jour l'action de contact, afin de nous servir de ce
.. note::
Bien qu'il soit facile de créer des paramètres de configuration par cette méthode, Symfony2 propose également une méthode dans laquelle on
- `expose une configuration sémantique <http://symfony.com/doc/current/cookbook/bundles/extension.html>`_ pour le bundle. Nous détaillerons cette méthode plus loin dans le tutorial.
+ `expose une configuration sémantique <http://symfony.com/doc/current/cookbook/bundles/extension.html>`_ pour le bundle. Nous détaillerons cette méthode plus loin dans le tutoriel.
Créer un template pour les email
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -675,13 +674,13 @@ Le corps de l'email est décrit dans un template. Créez ce template dans ``src/
Le contenu de l'email est celui que l'utilisateur vient de soumettre.
-Vous avez peut-être remarqué que l'extension de ce template est différente de celle des autres templates que nous avons créé jusque là. Il utilise l'extension ``.txt.twig``. La première partie de l'extension, ``.txt``, spécifique le format du fichier à générer. Parmi les formats courants, on peut noter .txt, .html, .css, .js, .xml et .json. La seconde partie de l'extension définit quel moteur de template utiliser, dans le cas présent Twig. Une extension en ``.php`` signifierait l'utilisation de PHP pour le rendu du template.
+Vous avez peut-être remarqué que l'extension de ce template est différente de celle des autres templates que nous avons créés jusque là. Il utilise l'extension ``.txt.twig``. La première partie de l'extension, ``.txt``, spécifie le format du fichier à générer. Parmi les formats courants, on peut noter .txt, .html, .css, .js, .xml et .json. La seconde partie de l'extension définit quel moteur de template utiliser. Dans le cas présent Twig. Une extension en ``.php`` signifierait l'utilisation de PHP pour le rendu du template.
Lorsque vous soumettez une requête un email va être envoyé à l'addresse définie dans le paramètre ``blogger_blog.emails.contact_email``.
.. tip::
- Symfony2 nous permet de configurer le comportement de la librairie Swift Mailer lorsque l'on travaille dans des environnements de développement Symfony2 différents. Nous pouvons dès à présent voir celà dans l'environnement ``test``. Par défaut, la distribution standard de Symfony2 est configurée de telle sorte que Swift Mailer n'envoit pas d'emails lorsque l'application est dans l'environnement ``test``. C'est défini dans le fichier ``app/config/config_test.yml``.
+ Symfony2 nous permet de configurer le comportement de la librairie Swift Mailer lorsque l'on travaille dans des environnements de développement Symfony2 différents. Nous pouvons dès à présent voir cela dans l'environnement ``test``. Par défaut, la distribution standard de Symfony2 est configurée de telle sorte que Swift Mailer n'envoie pas d'emails lorsque l'application est dans l'environnement ``test``. C'est défini dans le fichier ``app/config/config_test.yml``.
.. code-block:: yaml
@@ -691,15 +690,15 @@ Lorsque vous soumettez une requête un email va être envoyé à l'addresse déf
Il pourrait être utile de dupliquer cette fonctionnalité pour l'environnement ``dev``. Après tout, vous ne voulez pas envoyer accidentellement un email à une adresse incorrecte au cours du développement. Pour cela, ajoutez la configuration ci dessus au fichier de configuration de l'environnement ``dev``, dans ``app/config/config_dev.yml``.
- Vous vous demandez peut-être comment il est possible que s'assurer que les emails sont envoyés, et plus précisémment quel est leur contenu, étant donné qu'ils ne sont plus envoyés à une adresse email. Symfony2 propose une solution à celà via la barre d'outil de développement. Lorsqu'un email est envoyé, une notification par email va apparaitre dans la barre d'outils, qui contient toutes les informations à propos de l'email que Swift Mailer aurait délivrée.
+ Vous vous demandez peut-être comment il est possible que s'assurer que les emails sont envoyés, et plus précisément quel est leur contenu, étant donné qu'ils ne sont plus envoyés à une adresse email. Symfony2 propose une solution à cela via la barre d'outil de développement. Lorsqu'un email est envoyé, une notification par email va apparaître dans la barre d'outils, qui contient toutes les informations à propos de l'email que Swift Mailer aurait délivrée.
.. image:: ../_static/images/part_2/email_notifications.jpg
:align: center
:alt: Symfony2 toolbar show email notifications
- Si vous réalisez une redirection après l'envoi d'un email, comme nous le faisons avec le formulaire de contact, vous devrez paramètre la valeur de ``intercept_redirects`` dans ``app/config/config_dev.yml`` à ``true`` afin de voir les notifications d'envoi d'email dans la barre d'outils.
+ Si vous réalisez une redirection après l'envoi d'un email, comme nous le faisons avec le formulaire de contact, vous devrez paramètrer la valeur de ``intercept_redirects`` dans ``app/config/config_dev.yml`` à ``true`` afin de voir les notifications d'envoi d'email dans la barre d'outils.
- Nous aurions pu à la place configurer Swift Mailer pour envoyer tous les emails à une adresse spécifique dans l'environnement ``dev`` en plaçant le code suivant dans le fichier de configuration de correspondant, ``app/config/config_dev.yml``.
+ Nous aurions pu configurer Swift Mailer pour envoyer tous les emails à une adresse spécifique dans l'environnement ``dev`` en plaçant le code suivant dans le fichier de configuration de correspondant, ``app/config/config_dev.yml``.
.. code-block:: yaml
@@ -710,6 +709,6 @@ Lorsque vous soumettez une requête un email va être envoyé à l'addresse déf
Conclusion
----------
-Nous avons présenté les concepts derrière un des aspects les plus fondamentaux de n'importe quel site web: les formulaires. Symfony2 propose une excellente librairie de formulaires et de validateurs qui nous permet de séparer la logique de validation du formulaire de telle sorte qu'elle puisse être utilisée ailleurs dans l'application (dans le modèle par exemple). Nous avons également vu comment mettre en place des paramètres de configuration personnalisés qui peuvent être utilisés dans l'application, et nous avons également vu comment envoyer des emails grâce à la librairie Swift Mailer.
+Nous avons présenté les concepts derrière un des aspects les plus fondamentaux de n'importe quel site web: les formulaires. Symfony2 propose une excellente librairie de formulaires et de validateurs qui nous permet de séparer la logique de validation du formulaire de telle sorte qu'elle puisse être utilisée ailleurs dans l'application (dans le modèle par exemple). Nous avons également vu comment mettre en place des paramètres de configuration personnalisés qui peuvent être utilisés dans l'application. Enfin nous avons vu comment envoyer des emails grâce à la librairie Swift Mailer.
-Dans la prochaine partie, nous allons aborder un des grands axes de ce tutorial, le modèle. Nous allons présenter Doctrine 2 et nous en servir pour construire notre modèle pour les articles, et construire la page d'affichage des articles, et explorer le thème des données factices.
+Dans la prochaine partie, nous allons aborder un des grands axes de ce tutoriel, le modèle. Nous allons présenter Doctrine 2 et nous en servir pour construire notre modèle pour les articles, construire la page d'affichage des articles, et explorer le thème des données factices.
Something went wrong with that request. Please try again.