table des matières
Félicitations! En apprenant à connaître Symfony2, vous êtes bien sur le chemin d'une économie plus productive, développeur web. Symfony2 est construit pour revenir à l'essentiel: développer des outils qui vous permettent de développer plus rapidement et de construire des applications plus robustes. Symfony est construit sur les meilleures idées de nombreuses technologies: les outils et concepts que vous êtes sur le point de connaître représentent les efforts de milliers de personnes, depuis de nombreuses années. En d'autres termes, vous n'êtes pas en train d'apprendre "Symfony", vous apprenez les principes fondamentaux des pratiques de développement web les meilleurs, et comment utiliser de nombreux modèles de nouvelles librairies PHP, à l'intérieur ou indépendant de Symfony2. Alors, préparez-vous.
Fidèle à la philosophie Symfony2, ce chapitre commence par expliquer le concept fondamental commun pour le développement web: HTTP. Quel que soit votre arrière-plan ou langage de programmation préféré, ce chapitre est à lire absolument pour tout le monde.
HTTP (Hypertext Transfer Protocol à l'geeks) est un texte en langage qui permet à deux machines de communiquer les uns avec les autres. Ça y est! Par exemple, lors de la vérification pour la dernière xkcd bande dessinée, ce qui suit (approximative) de conversation a lieu:
Et tandis que la langue effectivement utilisée est un peu plus formelle, c'est encore plus simple. HTTP est le terme utilisé pour décrire ce simple basé sur le texte de langue. Et peu importe comment vous développer sur le web, le but de votre serveur est toujours de comprendre les demandes de textes simples, et de retourner les réponses textuelles simples.
Symfony2 est construit autour de cette réalité. Que vous le réalisiez ou non, HTTP est quelque chose que vous utilisez tous les jours. Avec Symfony2, vous allez apprendre à le maîtriser.
Chaque conversation sur le web commence par une demande. La demande est un message texte créé par un client (par exemple un navigateur, une application iPhone, etc) dans un format spécial connu sous le nom HTTP. Le client envoie cette demande à un serveur, puis attend la réponse.
Jetez un oeil à la première partie de l'interaction (la demande) entre un navigateur et le serveur web xkcd:
Dans HTTP-parler, cette requête HTTP serait effectivement ressembler à ceci:
GET / HTTP/1.1 Host: xkcd.com Accept: text/html User-Agent: Mozilla/5.0 (Macintosh)
Ce message simple communique tout ce qu'il faut savoir exactement quelle ressource le client demande. La première ligne d'une requête HTTP est la plus importante et contient deux choses: l'URI et la méthode HTTP.
L'URI (par exemple /, /contact, etc) est une adresse unique ou d'un emplacement qui identifie la ressource que le client veut. La méthode HTTP (GET par exemple) définit ce que vous voulez faire avec la ressource. Les méthodes HTTP sont les verbes de la demande et définir les moyens peu communs que vous pouvez agir sur la ressource:
| GET | Récupérer la ressource à partir du serveur |
| POST | Créer une ressource sur le serveur |
| PUT | Mettre à jour la ressource sur le serveur |
| DELETE | Supprimer la ressource à partir du serveur |
C'est dans cet esprit, vous pouvez imaginer ce que d'une requête HTTP pourrait ressembler à supprimer une entrée de blog spécifique, par exemple:
DELETE /blog/15 HTTP/1.1
Il y a en fait neuf méthodes HTTP définies par la spécification HTTP, mais beaucoup d'entre eux ne sont pas largement utilisés ou pris en charge. En réalité, de nombreux navigateurs modernes ne prend pas en charge les méthodes PUT et DELETE.
En plus de la première ligne, une requête HTTP contient toujours d'autres lignes d'information appelées têtes de requête. Les en-têtes peuvent fournir un large éventail d'informations telles que l'hôte lui a demandé, les formats de réponse du client accepte (Accepter) et l'application que le client utilise pour faire la demande (User-Agent). De nombreux autres en-têtes existent et peuvent être trouvés sur Wikipedia Liste des champs d'en-tête HTTP article.
Une fois qu'un serveur a reçu la demande, il sait exactement quelle ressource le client des besoins (via l'URI) et ce que le client veut faire de cette ressource (via la méthode). Par exemple, dans le cas d'une demande GET, le serveur prépare la ressource et le renvoie dans une réponse HTTP. Considérez la réponse du serveur Web xkcd:
Traduit en HTTP, la réponse envoyée au navigateur devrait ressembler à ceci:
HTTP/1.1 200 OK Date: Sat, 02 Apr 2011 21:05:05 GMT Server: lighttpd/1.4.19 Content-Type: text/html <html> <!-- HTML for the xkcd comic --> </html>
La réponse HTTP contient la ressource demandée (le contenu HTML dans ce cas), ainsi que d'autres informations sur la réponse. La première ligne est particulièrement importante et contient le code de réponse HTTP état (200 dans ce cas). Le code d'état communique le résultat global de la demande de rappel au client. Était ce la demande du succès? Y a t-il une erreur? Les codes d'état existent différents qui indiquent succès ou erreur, ou que le client a besoin de faire quelque chose (par exemple rediriger vers une autre page). Une liste complète peut être trouvée sur Wikipedia Liste des codes de statut HTTP article.
Comme la demande, une réponse HTTP contient des morceaux d'informations supplémentaires connues sous le nom en-têtes HTTP. Par exemple, un en-tête de réponse HTTP est important de Content-Type. Le corps de la même ressource pourrait être retourné dans plusieurs formats différents, comme HTML, XML, JSON ou et l' en-tête Content-Type utilise Internet comme types de médias text/html pour indiquer au client dont le format est retourné. Une liste de types de supports communs peuvent être trouvés sur Wikipedia Liste des types de médias communs article.
Il existe beaucoup d'autres en-tête ( header ), dont certains sont très puissants. Par exemple, certaines en-têtes peuvent être utilisées pour créer un système de cache puissant.
Ces requête-réponses sont les processes fondamentaux qui animent toutes les communications sur le web. Et tout aussi important et puissant que ce processus est, c'est inévitablement simple.
Le fait le plus important est ceci: quelle que soit la langue que vous utilisez, le type d'application que vous construisez (web, mobile, JSON API), ou la philosophie de développement que vous suivez, l'objectif final d'une demande est toujours à comprendre chaque demande et de créer des et retourner la réponse appropriée.
Symfony est architecturé pour correspondre à cette réalité.
Pour en savoir plus sur la spécification HTTP, lire l'original HTTP 1.1 RFC ou le Bis HTTP , qui est un effort actif pour clarifier la spécification originale. Un excellent outil pour vérifier à la fois la demande et en-têtes de réponse lors de la navigation est le Live HTTP Headers extension pour Firefox.
Alors, comment voulez-vous interagir avec la «requête» et de créer une «réponse» lorsque vous utilisez PHP? En réalité, abstraction PHP vous un peu de l'ensemble du processus:
<?php $uri = $_SERVER['REQUEST_URI']; $foo = $_GET['foo']; header('Content-type: text/html'); echo 'The URI requested is: '.$uri; echo 'The value of the "foo" parameter is: '.$foo;
Aussi étrange que cela puisse paraître, cette petite application est en fait prendre des informations à partir de la requête HTTP et l'utiliser pour créer une réponse HTTP. Au lieu d'analyser le message de requête brute HTTP, PHP prépare variables superglobales telles que $_SERVER et $_GET qui contiennent toutes les informations de la requête. De même, au lieu de retourner la réponse HTTP au format texte, vous pouvez utiliser la fonction header() pour créer les en-têtes de réponse et il suffit d'imprimer le contenu réel qui sera la partie du contenu du message de réponse. PHP va créer une véritable réponse HTTP et le retourner au client:
HTTP/1.1 200 OK Date: Sat, 03 Apr 2011 02:14:33 GMT Server: Apache/2.2.17 (Unix) Content-Type: text/html The URI requested is: /testing?foo=symfony The value of the "foo" parameter is: symfony
Symfony fournit une alternative à l'approche brute PHP via deux classes qui vous permettent d'interagir avec la requête et de réponse HTTP dans une voie plus facile. La classe Request est un objet simple représentation orientée message de requête HTTP. Avec elle, vous avez toutes les informations requête au bout des doigts:
use Symfony\Component\HttpFoundation\Request; $request = Request::createFromGlobals(); // the URI being requested (e.g. /about) minus any query parameters $request->getPathInfo(); // retrieve GET and POST variables respectively $request->query->get('foo'); $request->request->get('bar', 'default value if bar does not exist'); // retrieve SERVER variables $request->server->get('HTTP_HOST'); // retrieves an instance of UploadedFile identified by foo $request->files->get('foo'); // retrieve a COOKIE value $request->cookies->get('PHPSESSID'); // retrieve an HTTP request header, with normalized, lowercase keys $request->headers->get('host'); $request->headers->get('content_type'); $request->getMethod(); // GET, POST, PUT, DELETE, HEAD $request->getLanguages(); // an array of languages the client accepts
En prime, la classe Request fait beaucoup de travail en arrière-plan que vous n'aurez jamais besoin d'effectuer. Par exemple, la méthode isSecure() vérifie les trois valeurs différentes en PHP qui peuvent indiquer si oui ou non l'utilisateur se connecte via une connexion sécurisée (c.-à-https).
Comme on le voit ci-dessus, les variables $_POST $_GET sont accessibles via la requête publique et propriétés de la requête, respectivement. Chacun de ces objets est un objet ParameterBag, qui comporte des méthodes comme get(), has(), all() et plus encore. En fait, tous les propriétés publics utilisés dans l'exemple précédent est une instance de la ParameterBag.
La classe Request a également des attributs publiques, qui contiennent des données spécifiques relatives à la façon dont l'application fonctionne en interne. Pour le cadre Symfony2, les attributs détiennent les valeurs retournées par la route adapté, comme _controller, id (si vous avez un joker {id}), et même le nom de l'itinéraire adapté (_route). La propriété des attributs existe entièrement à être un endroit où vous pouvez préparer et stocker des informations spécifiques au contexte de la requête.
Symfony fournit également une classe de réponse: une représentation PHP simple d'un message de réponse HTTP. Cela permet à votre application pour utiliser une interface orientée objet pour construire la réponse qui doit être retournée au client:
use Symfony\Component\HttpFoundation\Response; $response = new Response(); $response->setContent('<html><body><h1>Hello world!</h1></body></html>'); $response->setStatusCode(200); $response->headers->set('Content-Type', 'text/html'); // prints the HTTP headers followed by the content $response->send();
Si Symfony n'offrait rien d'autre, vous auriez déjà une boîte à outils pour accéder facilement aux informations requête et d'une interface orientée objet pour la création de la réponse. Même si vous apprenez les nombreuses fonctionnalités puissantes dans Symfony, gardez à l'esprit que l'objectif de votre requête est toujours d'interpréter une requête et de créer la réponse appropriée en fonction de votre logique d'application.
Les classes Request et Response font parties d'un composant autonome inclus avec Symfony appelé HttpFoundation. Ce composant peut être utilisé de façon entièrement indépendante de Symfony et fournit également des classes pour la manipulation des sessions et les téléchargements de fichiers.
Comme HTTP lui-même, la requête et de réponse des objets sont assez simples. La partie la plus difficile de construire une application est écrit ce qui vient entre les deux. En d'autres termes, le vrai travail vient par écrit le code qui interprète la requête d'information et crée la réponse.
Votre requête n'a probablement beaucoup de choses, comme l'envoi d'e-mails, traitement des requêtes soumises forme, sauver les choses à une base de données, le rendu des pages HTML et de la protection de contenu et sécurité. Comment pouvez-vous gérer tout cela et toujours garder votre code et maintenable organisée?
Symfony a été créé pour résoudre ces problèmes.
Traditionnellement, les applications ont été construites de sorte que chaque «page» d'un site est son propre fichier physique:
index.php contact.php blog.php
Il y a plusieurs problèmes avec cette approche, y compris la rigidité de l'URL (si vous vouliez changer blog.php à news.php sans casser l'ensemble de vos liens?) Et le fait que chaque dossier doit inclure manuellement un ensemble de fichiers de base de sorte que les connexions de sécurité de base de données, et le "look" du site peut rester cohérent.
Une bien meilleure solution est d'utiliser un contrôleur frontal : un seul fichier PHP qui gère toutes les requêtes à venir dans votre application. Par exemple:
| /index.php | executes index.php |
| /index.php/contact | executes index.php |
| /index.php/blog | executes index.php |
Utilisation de mod_rewrite d'Apache (ou équivalent avec d'autres serveurs Web), l'URL peut être facilement nettoyé pour être juste /, /contact et /blog.
Maintenant, chaque requête est traitée exactement pareille. Au lieu d'URL individuelles d'exécution différents fichiers PHP, le contrôleur frontal est toujours exécuté, et le routage des URL différentes pour différentes parties de votre application se fait en interne. Cela résout les deux problèmes avec l'approche originale. Près de toutes les applications web modernes ce faire - y compris les applications telles que WordPress.
Mais à l'intérieur de votre contrôleur frontal, comment savez-vous quelle page doit être rendue et comment pouvez-vous les rendre chacun saine chacune à leur manière ? D'une façon ou une autre, vous aurez besoin de vérifier l'URI entrant et exécuter différentes parties de votre code en fonction de cette valeur. Cela peut devenir réalisé rapidement:
// index.php $request = Request::createFromGlobals(); $path = $request->getPathInfo(); // the URI path being requested if (in_array($path, array('', '/')) { $response = new Response('Welcome to the homepage.'); } elseif ($path == '/contact') { $response = new Response('Contact us'); } else { $response = new Response('Page not found.', 404); } $response->send();
Résoudre ce problème peut être difficile. Heureusement, Symfony est conçu pour faire.
Quand vous laissez Symfony traiter chaque requête, la vie est beaucoup plus facile. Symfony suit le même schéma simple pour chaque requête:
Les requêtes entrantes sont interprétées par le routage et transmis aux fonctions de contrôle qui retournent des objets de réponse.
Chaque "page" de votre site est définie dans un fichier de configuration de routage que les cartes des URL différentes pour différentes fonctions PHP. Le travail de chaque fonction PHP, appelé contrôleur de , est d'utiliser les informations de la requête - ainsi que de nombreux autres outils Symfony met à la disposition - de créer et de retourner un objet de réponse. En d'autres termes, le contrôleur est l'endroit où votre code va: c'est l'endroit où vous interprétez la requête et de créer une réponse.
C'est si facile! Passons en revue:
Sans plonger dans trop de détails, nous allons voir ce processus en action. Supposons que vous souhaitez ajouter une page /contact pour votre application Symfony. Tout d'abord, commencez par ajouter une entrée pour /contact pour votre fichier de configuration de routage:
contact: pattern: /contact defaults: { _controller: AcmeDemoBundle:Main:contact }
Cet exemple utilise YAML pour définir la configuration du routage. Routage de configuration peut également être écrite dans d'autres formats tels que XML ou PHP.
Quand quelqu'un visite la page /contact, cette voie est adaptée, et le contrôleur spécifiée est exécutée. Comme vous le verrez dans le chapitre de routage, AcmeDemoBundle:Main:contact est une syntaxe plus courte qui pointe vers une méthode spécifique à l'intérieur d'une classe appelée MainController:
class MainController { public function contactAction() { return new Response('<h1>Contact us!</h1>'); } }
Dans cet exemple très simple, le contrôleur crée simplement un objet de réponse avec le code HTML "<h1> Contactez-nous! </ h1>". Dans le chapitre sur le contrôleur, vous apprendrez comment un contrôleur peut rendre les modèles, permettant à votre "présentation" du code (c.-à-rien qui écrit réellement sur HTML) de vivre dans un fichier de modèle distinct. Cela permet de libérer le contrôleur de se préoccuper uniquement de la substance dure: l'interaction avec la base de données, traitement des données soumises, ou en envoyant des e-mails.
Vous savez maintenant que l'objectif de n'importe quelle application consiste à interpréter chaque requête entrante et de créer une réponse appropriée. Comme une application grandit, il devient plus difficile de garder votre code maintenable. Invariablement, les mêmes tâches complexes continuent d'affluer maintes et maintes fois: les choses qui persistent à la base de données, ce qui rend la réutilisation et modèles, la manipulation soumission de formulaire, l'envoi de courriels, la validation des entrées utilisateur et la sécurité de manipulation.
Les bonnes nouvelles, c'est qu'aucun de ces problèmes est unique. Symfony fournit un cadre complet d'outils qui vous permettent de construire votre application, et non pas vos outils. Avec Symfony2, rien n'est imposé sur vous: vous êtes libre d'utiliser le framework Symfony complète, ou juste un morceau de Symfony par lui-même.
Alors, quelle est Symfony2? Tout d'abord, Symfony2 est une collection de plus de vingt bibliothèques indépendantes qui peuvent être utilisés à l'intérieur de tout projet PHP. Ces bibliothèques, appelé les Symfony2 Composants, contiennent quelque chose d'utile pour presque n'importe quelle situation, quel que soit la façon dont votre projet est développé. Pour n'en nommer que quelques-uns:
Chacun et chacune de ces composantes est découplé et peut être utilisé dans n'importe quel projet PHP, indépendamment du fait que vous utilisiez ou non le cadre Symfony2. Chaque pièce est faite pour être utilisée en cas de besoin et remplacés si nécessaire.
Alors, quel est le cadre Symfony2? Le Cadre Symfony2 est une bibliothèque PHP qui accomplit deux tâches distinctes:
L'objectif du cadre est d'intégrer de nombreux outils indépendants afin de fournir une expérience cohérente pour le développeur. Même le cadre lui-même est un faisceau Symfony2 (c.-à-un plugin) qui peut être configuré ou entièrement remplacé.
Symfony2 fournit un ensemble puissant d'outils pour développer rapidement des applications Web sans imposer à votre requête. Les utilisateurs normaux peuvent démarrer rapidement le développement en utilisant une distribution Symfony2, qui fournit un squelette de projet avec bon sens par défaut. Pour les utilisateurs plus avancés, le ciel est la limite.