webnel-blog - Tumblr blog

webnel-blog · 13 years ago

Text

Webnel va utiliser Symfony2

Webnel passe désormais à Symfony2. Je vais ici retracer le pourquoi du comment et vous dire ce que cela change pour vous... et pour moi.

Pourquoi Symfony ?

C'est finalement très simple.

À l'origine, Webnel utilisait son propre framework MVC fait maison. C'était lourd, relativement peu sécurisé au début, et très peu productif. En effet, je passais plus de temps à corriger les bugs du framework et à ajouter de nouvelles fonctionnalités qu'à réaliser Webnel.

Quelques temps plus tard, j'ai désiré utiliser le Zend Framework. Certes, c'était bien plus aisé de développer avec, mais finalement, le problème était plus ou moins le même. Et ce parce que Zf ne fait pas tout. Il gère le côté MVC, ça, c'est très bien — bien que j'ai du faire pas mal de modifications de ce côté là pour pouvoir importer les routes d'un peu partout —, ainsi que la traduction, la sécurité... Mais il gère moins bien tout ce qui concerne les utilisateurs — partie que j'ai du intégralement réaliser moi-même. Et puis Zf n'intègre pas nativement une structure solide, comme c'est le cas de Symfony2, ni la génération de code. Et ce point est essentiel.

Entre temps, Symfony2 est passé en version stable. Je m'y suis alors intéressé. Et maintenant, je vais l'utiliser.

Qu'est-ce que ça change pour moi ? Plein de choses. Voyez plutôt :

Tout d'abord, Symfony apporte une grande rigueur dans le développement, rigueur qui est très bénéfique. Structure du projet, fichiers de configurations dispatchés... Tout ceci participe à simplifier la gestion des sources : tout est à la place qu'il doit avoir, sans empiéter sur le reste, et l'ensemble est très cohérent. L'exemple est flagrant quand on se renseigne sur l'utilisation des Bundles. Pour ceux qui ne connaissent pas Symfony2, cela correspond en gros aux grosses parties du sites, des modules en quelques sortes. Ces Bundles, donc, apportent une grande structure aux différentes parties du projet, ainsi qu'une grande flexibilité.

Deuxième point, et pas des moindres, la génération de code. En effet, Symfony permet de générer automatiquement des fichiers de configuration, de description, voir tout un Bundle. Cette génération est appréciable en deux points : primo, on gagne du temps (pas besoin de créer tout les fichiers/dossiers, en faisant attention aux noms, de créer les classes de description du Bundle... Symfony2 le fait pour nous) ; secundo, et c'est lié, vu que le code est généré, il n'y a pas de bugs. Et ça, c'est un gros plus.

Troisième point : l'ORM. Symfony nous met à disposition un excellent système d'abstraction de la base de donnée : Doctrine. Cet outil permet de ne plus penser en tables et colonnes, mais en classes et attributs. Et ça, c'est cool. En effet, Doctrine se charge de tout. Pour créer une table, il suffit de créer une classe qui la décrit. D'ailleurs, il n'est parfois même pas nécessaire de la créer : grâce à la génération de code, il suffit de lister les attributs, et Doctrine nous génère la classe tout seul, comme un grand. Pas de temps perdu. Pas de bugs. Que du bonheur. Et après ? Pour ajouter un enregistrement, il suffit d'instancier la classe, de modifier les attributs et de les donner en pâture à Doctrine. Il s'occupe de générer la/les requêtes (en faisant attention à ce qu'il y en ait le moins possible, et sans négliger la sécurité) et de mettre la table à jour. Pour mettre à jour, c'est presque pareil. Pour supprimer un enregistrement, il suffit de lui donner une clef primaire (l'ID, quoi). Même principe pour en obtenir, et dans ce cas, on obtient la classe de tout à l'heure pré-remplie. Et bien sur, Doctrine supporte les requêtes un peu plus complexes. Pour la sélection de données, ils ont créés en effet leur propre DQL (Doctrine Query Language). C'est un peu comme le SQL, sauf qu'au lieu de raisonner en tables et colonnes, on résonne en classes et attributs. Cool, non ?

Autre chose, les formulaires. Un peu à la manière de Doctrine, Symfony2 permet de générer automatiquement les formulaires, à partir d'une classe modèle. On lui donne la classe, et les champs à mettre, ainsi que leurs types ; après, Symfony se charge de tout. Il ne reste plus qu'à afficher le formulaire.

Tiens, et à propos d'affichage, autre énoooooooooooorme avantage de Symfony2 : Twig, son moteur de templates. C'est un système extrêmement puissant qui permet de gérer les vues de l'application très facilement. Il y a plein de fonctions intégrées et tout et tout ; c'est super cool.

Par ailleurs, Symfony2 est très rapide. Et ce car il utilise un système de cache puissant : le cache HTTP. Et franchement, c'est bufflant. Si la première page est assez longue à charger (bah oui, tout est mis en cache à ce moment là), après, c'est quasi-instantané.

Autre chose de bien : le système d'événements intégré à Symfony (implémentant le pattern Observer, pour les connaisseurs). C'est d'ailleurs sur lui que tout Symfony repose. Le principe est simple : lors de certains événements — comme la requête, la réponse, une exception... —, le noyau de Symfony va avertir — en appelant une méthode — tout les listeners qui l'ont demandé. Et l'on peux bien sur créer ses propres listeners ET événements. D'ailleurs, je ne vous cache pas que le système d'add-ons de Webnel sera en partie basé dessus ;) .

Enfin, je ne vous parlerai pas de l'excellent environnement de développement mis à disposition des développeurs par Symfony (enfin si, bien sur). Prenons un exemple simple : le lancement d'une exception non attrapée. En PHP plat, cela va produire l'affichage d'un bloc de texte (sauf si vous développez en texte brut, mais bon...) contenant le libellé de l'exception, le fichier, la ligne, la pile d'appel (dans une liste à tirets sans retour à la ligne, liste donc totalement illisible sans regarder la source), et... c'est tout. Sous Symfony, c'est différend. Vos visiteurs ne verrons rien de tout cela : uniquement une « erreur interne au serveur » — une erreur 500, quoi. Ce qui implique qu'aucune information potentiellement sensible ne risque d'être divulguée à un éventuel pirate. Pour vous, par contre, c'est beaucoup plus intéressant. Vous verrez une page récapitulant l'erreur, le composant qui l'a envoyée, le fichier présenté au format Symfony — ce qui facilite son identification —, la ligne dans le fichier concerné, l'erreur HTTP lancée, la pile d'appel (avec en bonus un extrait du code « incriminé » de chaque élément de la pile), ainsi que les logs de Symfony ajoutés dans cette page. Voyez plutôt (ceci est une capture d'écran) (d'ailleurs, si vous regardez les logs de plus près, vous pourrez constater que oui, Symfony est presque entièrement basé sur l'écoute d'événements). Autre chose, et pas des moindres : la Web Development Toolbar. C'est une barre qui s'affiche en bas de chaque page (par défaut, uniquement en environnement de développement) et qui récapitule un grand nombre d'informations utiles. Il y a, dans l'ordre, la version de Symfony, celle de PHP, la configuration actuelle de Symfony, la requête (avec le contrôleur, l'action, le nom de la route et le code d'erreur HTTP) , le nombre d'exception lancées (le cas échéant), le temps de chargement et le poids de la page, l'état de l'authentification, pour finir par le nombre de requêtes. Et en prime, l'on peut obtenir un rapport détaillé (vraiment détaillé) en cliquant sur chacune des icônes (sauf ce qui concerne le temps de chargement et le poids de la page). Voici une capture d'écran de la barre en question.

C'est bon, j'en ai assez dit ? ^^

Et pour les développeurs ? Pour les utilisateurs ?

Les utilisateurs, même s'ils ne voient pas directement Symfony, disposent d'un outil bien plus rapide, plus réactif. Et plus sécurisé, aussi : il n'y a quasiment plus de failles si on fait un peu attention. Donc ils peuvent être tranquilles.

Pour les développeurs, ils disposent de la puissance de Symfony2. En effet, depuis le passage à Symfony, le système de composants externes a été repensé. Chaque composant (sauf les templates et les add-ons) deviennent des Bundles. Et à partir de là...

Donc ?...

Finalement, Symfony2 apporte certes un changement radical dans la manière de concevoir le développement web, mais une fois le temps d'adaptation passé, c'est que du bonheur. C'est puissant. C'est simple. C'est rapide... Enfin voilà, quoi.

En gros (si vous n'aviez pas encore compris), je vous recommande chaudement d'au moins vous intéresser à Symfony2. Juste pour voir. Et pourquoi pas, utilisez-le dans vos projets ! Même pour un petit projet, il tire son épingle du jeu (enfin petit... tout est relatif ! N'allez pas utiliser Symfony2 pour un petit site statique de 5 pages ^^). N'hésitez pas !

Autre chose...

Qui dit nouveau framework dit nouveau dépôt de source. Vous pourrez suivre cette version de Webnel grâce au dépôt SVN situé à cette adresse.

PS : non, ce billet n'est pas sponsorisé par SensioLabs ;) .

#framework #symfony #développement

49 notes · View notes

webnel-blog · 14 years ago

Text

Préliminaire : Webnel ?

Bonjour. Ce blog me servira par la suite à vous informer de l'évolution de Webnel.

Ce message ne sert que d'introduction. Je ne développerai pas grand chose ici. Cependant, dés que j'aurai un peu plus de temps — c'est à dire une prochaine fin de semaine — je vous dirai tout.

Mais commençons par une question fondamentale : qu'est-ce que Webnel ?

Qu'est-ce que Webnel, au juste ? Un énième CMS ?

Non. Clairement non.

En effet, je ne désire pas que Webnel soit un CMS basique, avec les options minimales. Non, ma vision, c'est d'en faire un CMS accessible à tous. Pour qu'il ne soit plus nécessaire d'être geek ou informaticien pour créer un site web professionnel, bien fait, cohérent.

Si on regarde les sites persos actuels, on s'aperçoit vite qu'ils sont souvent bâclés, mal faits, à la vas-vite, sans aucune cohérence, sécurité (dans les cas des sites un peu dynamiques) et en prime un horrible compteur de visite extrêmement mal intégré.

Ce n'est pas ce que je veux pour Webnel. Non, je désire que Webnel permette à M. Tout-Le-Monde de créer un site complet, bien fait, avec des « widgets » bien intégrés, et surtout facilement. Il ne faut pas que les utilisateurs aient besoin d'utiliser l'aide.

Finalement, les objectifs de Webnel sont au nombre de six :

Simplicité ;

Extensibilité ;

Flexibilité ;

Puissance ;

Adaptation à tout type de site ;

Sécurité.

Idéalement, il cumulera les avantages des différends CMS du marché — squelettes de SPIP, modularité de Drupal, facilité d'utilisation de Joomla!... — en oubliant leurs inconvénients. Je vous détaillerais comment je compte arriver à un tel but dans un futur article.

Encore une chose...

J'entends d'ici les septiques, affirmant :

« Encore un utopiste qui croit qu'il va révolutionner le monde avec un énième CMS... »

Je sais qu'il est facile d'avoir cet avis — d'ailleurs, je me pose moi-même la question, parfois — ; cependant, je ne compte pas m'arrêter en chemin. Je désire réellement mener ce projet à terme. Et si possible avec succès.

#introduction #objectifs

2 notes · View notes