Apprendre à Développer des applications web avec Symfony2
Apprendre à Développer des applications web avec Symfony2
… … …
Requêtes et réponses dans Symfony
Symfony offre une alternative à l’approche PHP brute via deux classes qui vous permettent d’interagir plus facilement avec la requête et la réponse HTTP. La classe Request est une simple représentation orientée objet du message de requête HTTP. Avec lui, vous avez toutes les informations de la demande à portée de main:
utilisez Symfony \ Component \ HttpFoundation \ Request;
$ request = Request :: createFromGlobals ();
// l'URI demandé (par exemple / about) moins les paramètres de la requête
$ request-> getPathInfo ();
// récupère les variables GET et POST respectivement
$ request-> query-> get ('foo');
$ request-> request-> get ('bar', 'valeur par défaut si bar n'existe pas');
// récupère les variables du serveur
$ request-> server-> get ('HTTP_HOST');
// récupère une instance de UploadedFile identifiée par foo
$ request-> files-> get ('foo');
// récupère une valeur COOKIE
$ request-> cookies-> get ('PHPSESSID');
// récupère un en-tête de requête HTTP, avec des clés normalisées en minuscules
$ request-> headers-> get ('hôte');
$ request-> headers-> get ('type_contenu');
$ request-> getMethod (); // GET, POST, PUT, DELETE, HEAD
$ request-> getLanguages (); // un tableau de langues acceptées par le client
En prime, la classe de demande effectue beaucoup de travail en arrière-plan dont vous n'aurez jamais à vous soucier.
Par exemple, la méthode isSecure () vérifie les trois valeurs différentes en PHP qui peuvent indiquer si l’utilisateur se connecte ou non via une connexion sécurisée (c'est-à-dire https). Attributs arameterBags et Request
Comme indiqué ci-dessus, les variables $ _GET et $ _POST sont accessibles via les propriétés de requête et de requête publiques, respectivement. Chacun de ces objets est un objet ParameterBag, qui a des méthodes comme get (), has (), all () et plus. En fait, chaque propriété publique utilisée dans l'exemple précédent est une instance du ParameterBag.
La classe Request possède également une propriété d'attributs publics, qui contient des données spéciales liées au fonctionnement interne de l'application. Pour le framework Symfony2, les attributs contiennent les valeurs renvoyées par la route correspondante, comme _controller, id (si vous avez un caractère générique {id}) et même le nom de la route correspondante (_route). La propriété d'attributs existe entièrement pour être un endroit où vous pouvez préparer et stocker des informations contextuelles sur la demande.
Symfony fournit également une classe de réponse: une simple représentation PHP d’un message de réponse HTTP.
Cela permet à votre application d'utiliser une interface orientée objet pour construire la réponse qui doit être renvoyée au client:
utilisez Symfony \ Component \ HttpFoundation \ Response;
$ response = new Response ();
$ response-> setContent ('<html> <body> <h1> Bonjour tout le monde! </ h1> </ body> </ html>');
$ response-> setStatusCode (200);
$ response-> headers-> set ('Content-Type', 'text / html');
// affiche les en-têtes HTTP suivis du contenu
$ réponse-> send ();
Si Symfony n’offrait rien d’autre, vous disposeriez déjà d’une boîte à outils permettant d’accéder facilement aux informations relatives aux demandes et d’une interface orientée objet permettant de créer la réponse. Même si vous découvrez les nombreuses fonctionnalités puissantes de Symfony, n'oubliez pas que l'objectif de votre application est toujours d'interpréter une requête et de créer la réponse appropriée en fonction de la logique de votre application.
Les classes Request et Response font partie d'un composant autonome inclus avec Symfony appelé HttpFoundation. Ce composant peut être utilisé de manière totalement indépendante de Symfony et fournit également des classes permettant de gérer les sessions et les téléchargements de fichiers.
Le parcours de la demande à la réponse
Comme HTTP, les objets Request et Response sont assez simples. La partie difficile de la création d’une application est d’écrire ce qui se situe entre les deux. En d'autres termes, le vrai travail consiste à écrire le code qui interprète les informations de la demande et crée la réponse.
Votre application fait probablement beaucoup de choses, comme envoyer des courriels, gérer les envois de formulaires, enregistrer des éléments dans une base de données, afficher des pages HTML et protéger le contenu de manière sécurisée. Comment gérer tout cela tout en maintenant votre code organisé et maintenable?
Symfony a été créé pour résoudre ces problèmes afin que vous n'ayez pas à le faire.
Le contrôleur avant
Traditionnellement, les applications étaient construites de manière à ce que chaque "page" d'un site soit son propre fichier physique:
index.php
contact.php
blog.php
Cette approche pose plusieurs problèmes, notamment le manque de souplesse des URL (que se passe-t-il si vous souhaitez remplacer blog.php par news.php sans casser tous vos liens?) Et le fait que chaque fichier doit inclure manuellement un ensemble de fichiers de base afin que la sécurité, les connexions à la base de données et le "look" du site puissent rester cohérents.
Une solution bien meilleure consiste à utiliser un contrôleur frontal: un fichier PHP unique qui gère toutes les demandes entrant dans votre application. Par exemple:
/index.php exécute index.php
/index.php/contact exécute index.php
/index.php/blog exécute index.php
En utilisant mod_rewrite d’Apache (ou l’équivalent avec d’autres serveurs Web), les URL peuvent facilement être nettoyées pour n’être que /, / contact et / blog.
Désormais, chaque demande est traitée exactement de la même manière. Au lieu d'URL individuelles exécutant différents fichiers PHP, le contrôleur frontal est toujours exécuté et le routage d'URL différentes vers différentes parties de votre application est effectué en interne. Cela résout les deux problèmes avec l'approche originale. Presque toutes les applications Web modernes le font, y compris des applications telles que WordPress.
Restez organisé
Dans votre contrôleur frontal, vous devez déterminer quel code doit être exécuté et quel contenu doit être renvoyé. Pour comprendre cela, vous devez vérifier l'URI entrant et exécuter différentes parties de votre code en fonction de cette valeur. Cela peut devenir rapidement moche:
// index.php
utilisez Symfony \ Component \ HttpFoundation \ Request;
utilisez Symfony \ Component \ HttpFoundation \ Response;
$ request = Request :: createFromGlobals ();
$ path = $ request-> getPathInfo (); // le chemin de l'URI demandé
if (in_array ($ path, array ('', '/')))) {
$ response = new Response ('Bienvenue sur la page d'accueil.');
} elseif ($ path == '/ contact') {
$ response = new Response ('Contactez-nous');
} autre {
$ response = new Response ('Page introuvable.', 404);
}
$ réponse-> send ();
Résoudre ce problème peut être difficile. Heureusement, c'est exactement ce que Symfony est conçu pour faire.
Le flux d'applications Symfony
Lorsque vous laissez Symfony traiter chaque demande, la vie est beaucoup plus facile. Symfony suit le même modèle simple pour chaque demande:
Les demandes entrantes sont interprétées par le routage et transmises aux fonctions de contrôleur qui renvoient des objets Response.
Chaque "page" de votre site est définie dans un fichier de configuration de routage qui mappe différentes URL à différentes
Fonctions PHP. Le rôle de chaque fonction PHP, appelée contrôleur, est d’utiliser les informations de la requête - avec de nombreux autres outils mis à disposition par Symfony - pour créer et renvoyer un objet Response. En d'autres termes, le contrôleur est l'endroit où votre code va: c'est l'endroit où vous interprétez la demande et créez une réponse. C'est si facile! Réviser:
- chaque demande exécute un fichier de contrôleur frontal;
- Le système de routage détermine la fonction PHP à exécuter en fonction des informations de la demande et de la configuration de routage que vous avez créées.
- La fonction PHP correcte est exécutée, votre code crée et renvoie le code approprié.
Objet de réponse.
Une requête Symfony en action
Sans trop entrer dans les détails, voici le processus en action. Supposons que vous souhaitiez ajouter une page / contact à votre application Symfony. Commencez par ajouter une entrée pour / contact à votre fichier de configuration de routage:
# app / config / routing.yml
contact:
motif: / contact
valeurs par défaut: {_controller: AcmeDemoBundle: Main: contact}
Cet exemple utilise YAML pour définir la configuration du routage. La configuration du routage peut également être écrite dans d'autres formats tels que XML ou PHP.
Lorsque quelqu'un visite la page / contact, cet itinéraire est mis en correspondance et le contrôleur spécifié est exécuté.
Comme vous apprendrez dans le chapitre sur le routage, AcmeDemoBundle: Main: chaîne de contact est une syntaxe courte qui pointe vers une méthode PHP spécifique contactAction dans une classe appelée MainController:
// src / Acme / DemoBundle / Controller / MainController.php
utilisez Symfony \ Component \ HttpFoundation \ Response;
classe MainController
{
fonction publique contactAction ()
{
renvoie une nouvelle réponse ('<h1> Contactez-nous! </ h1>');
}
}
Dans cet exemple très simple, le contrôleur crée simplement un objet Response avec le code HTML
"<h1> Contactez-nous! </ h1>". Dans le chapitre sur les contrôleurs, vous apprendrez comment un contrôleur peut restituer des modèles, ce qui permet à votre code de "présentation" (c’est-à-dire tout ce qui écrit réellement en HTML) est inséré dans un fichier de modèle séparé. Cela permet au contrôleur de se préoccuper uniquement des tâches les plus ardues: interaction avec la base de données, gestion des données soumises ou envoi de courriers électroniques.
Symfony2: Construisez votre application, pas vos outils.
Vous savez maintenant que le but de toute application est d'interpréter chaque demande entrante et de créer une réponse appropriée. Au fur et à mesure que l'application grandit, il devient de plus en plus difficile de garder votre code organisé et maintenable. Invariablement, les mêmes tâches complexes reviennent sans cesse: conservation d'éléments dans la base de données, restitution et réutilisation de modèles, gestion des soumissions de formulaires, envoi de courriers électroniques, validation des entrées utilisateur et gestion de la sécurité.
La bonne nouvelle est qu’aucun de ces problèmes n’est unique. Symfony fournit un cadre complet d’outils vous permettant de construire votre application, pas vos outils. Avec Symfony2, rien ne vous est imposé: vous êtes libre d'utiliser l'intégralité du framework Symfony, ou juste un élément de Symfony à lui tout seul.
Outils autonomes: les composants Symfony2
Alors, quel est Symfony2? Premièrement, Symfony2 est une collection de plus de vingt bibliothèques indépendantes pouvant être utilisées dans tout projet PHP. Ces bibliothèques, appelées Composants Symfony2, contiennent quelque chose d’utile dans presque toutes les situations, quel que soit le mode de développement de votre projet. Pour en nommer quelques uns:
- HttpFoundation: contient les classes Request et Response, ainsi que d'autres classes permettant de gérer les sessions et les téléchargements de fichiers.
- Routage - Système de routage puissant et rapide qui vous permet de mapper un URI spécifique (par exemple,
/ contact) pour obtenir des informations sur le traitement de cette demande (par exemple, exécuter la méthode contactAction ());
- Form14
- un cadre complet et flexible pour la création de formulaires et le traitement des soumissions de formulaires;
- Validator15: un système permettant de créer des règles sur les données, puis de valider si les données soumises par l'utilisateur sont conformes à ces règles;
- ClassLoader Une bibliothèque à chargement automatique qui permet aux classes PHP d'être utilisées sans avoir besoin d'exiger manuellement les fichiers contenant ces classes.
- Templating Une boîte à outils pour le rendu des modèles, la gestion de l'héritage des modèles (c'est-à-dire qu'un modèle est décoré avec une mise en page) et l'exécution d'autres tâches de modèle communes;
- Security16 - Une bibliothèque puissante pour gérer tous les types de sécurité dans une application;
- Translation17 Un cadre pour la traduction de chaînes dans votre application.
