Aujourd’hui, je ne vous apprends rien, le développement web s’est considérablement professionnalisé et on ne fait plus de sites web comme on les faisait il y a 10 ans. Mais pourtant il y a bien des sites web qui ont encore 10 ans et n’ont jamais été refondu.

Pourquoi refondre quelque chose qui fonctionne me direz-vous ? Oui bonne question ! La principale me semble la maintenance et l’évolution du site qui devient au fil des années, compliquée voir quasi impossible.

Mais refondre un site from scratch n’est pas de tout repos et finalement peut-être pas la meilleur idée. Du coup, nous allons voir un cas pratique de migration en douceur d’un site “old scool”.

Le contexte

Nous parlons d’un site ici où chaque page web est représentée par une page php. Pas de rewrite. Chacune faisant un nombre incalculable de require, include, echo. Où beaucoup de développeurs sont passés par là, chacun sur le temps perso, pour la plupart le développement étant un loisir.
Pas la peine de vous faire un dessin, vous voyez le tableau.

L’objectif

Mettre en place une pseudo v2 progressive :
Recréer chacune des pages sur un nouveau socle applicatif plus actuel puis optimiser l’ensemble une fois toutes les pages crées. Les anciennes pages, doivent fonctionner avec les nouvelles sans changement dans les premières. En gros, tout le monde ne doit y voir que du feu.

Fonctionnement

Pour réaliser ça, je me suis pas foulé, je me suis tout simplement inspiré de ce que Fabien avait pris le temps de mettre par écrit dans sa série : “Create your own Framework”.

Du coup c’est plus la mise en pratique que je vais détailler. Nous allons donc migrer une page qui s’appelle : rechercheJoueur.php

Première étape, configurer notre nouvelle app en créant un fichier v2.php à la racine de notre serveur (vu que le vhost pointe ici) et contenant le code de l’étape 5 de fabien.
A partir de là, on a déjà quelque chose de sympa et quasi prêt à emploi. Faisons le test.

Dans notre app.php on va donc déclarer en route la première page qu’on va migrer. Genre ça:

<?php
use Symfony\Component\Routing;
 
$routes = new Routing\RouteCollection();
 
$routes->add('search', new Routing\Route('rechercheJoueur.php', array(
    '_controller' => 'render_template',
)));
 
return $routes;

On va c/c le contenu de notre ancienne page dans le dossier src/pages définies dans la fonction render_template en prenant soin de la renommer par search.php (nom de la route).

A ce niveau bien sûr, si vous accédez à l’ancienne url, vous tombez toujours sur l’ancienne page.
Nous allons donc créer un .htaccess à la racine avec tout simplement :

    RewriteEngine On
    RewriteBase /

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ v2.php [QSA,L]

Pas besoin de grand discours, en gros, tout les urls qui ne pointent pas sur une ressource existante, iront maintenant sur notre nouvelle application.

Renommons maintenant notre ancienne page. Et tentons d’y accéder (par son ancien nom) et magie, on pointe désormais sur la nouvelle page qui doit se comporter exactement comme l’ancienne vu que finalement, on a pas changé grand chose pour l’instant.

Mais le principal avantage c’est que toutes nos pages passent par le même endroit désormais.

Du coup la prochaine étape, est celle décrite dans la partie 6, utiliser HttpKernel et son ControllerResolver pour utiliser des controller en lieu et place de notre function render_template.

On pourra alors sortir tout le code php de notre page à migrer, et le mettre dans le controller en 1ere étape de séparation du code php / html.

Je me suis ensuite arrêté là niveau applicatif. J’ai trouvé que j’avais tous les éléments à ma disposition. Mais n’hésitez pas à continuer la suite de la série de Fabien.

Du coup, au lieu du DIC de Symfony2 dont Fabien parle dans l’étape 12, j’ai personnellement opté pour Pimple vu que le site n’est vraiment pas compliqué niveau technique et que je n’avais pas besoin de l’artillerie lourde de ce côté.

Du coup, j’ai injecté dans Pimple, une connexion DBAL de doctrine et twig comme moteur de template et j’ai décidé d’injecter directement tout ce container dans tous mes controllers (même si on est d’accord que c’est le mal) mais en l’état c’est pas vraiment problématique j’ai juste 2 services.

Du coup j’ai un peu modifié la partie concernant l’appel au controller dans mon v2.php pour reproduire le setContainer propre au ContainerAwareInterface mais qui attend un ContainerInterface du DIC. Pour utiliser Pimple dans nos containier, il faut donc reproduire ce setContainer.

try {
    $request->attributes->add($matcher->match($request->getPathInfo()));
 
    $controllers = $resolver->getController($request);
    // on instancie notre controller 
    $controller = new $controllers[0];
    // on récupère l'action
    $action = $controllers[1];
    // On injecte Pimple
    $controller->setContainer($container);
    // On récupère les arguments
    $arguments = $resolver->getArguments($request, $controllers);
 
    $response = call_user_func(array($controller, $action), $arguments);
} catch (Routing\Exception\ResourceNotFoundException $e) {
    $response = new Response('Not Found', 404);
} catch (Exception $e) {
    $response = new Response('An error occurred', 500);
}

Voilà, un peu brut, mais ca fait son job rapidement. Il suffira de créer un controller qui contiendra cette méthode setContainer et dont tous nos controllers hériteront. Et nous pourrons alors utiliser notre dbal et notre twig dans nos actions !

La suite n’est que du refactoring du code existant. Faites déjà fonctionner une page, essayant de découper les traitements dans des classes adéquates. Chaque nouvelle page, apportera son lot de cas particulier, mais plus ça ira et plus ce sera simple de migrer les pages.

Et ensuite ?

Je n’y suis pas encore, mais j’imagine qu’une fois qu’on s’est affranchi des contraintes de l’ancien système, on peut commencer à optimiser un peu, créer une couche modèle, peut-être envisager un ORM ? Ou tout simplement se dire, que c’est bien suffisant et que maintenant, n’importe quel dev avec une connaissance du MVC devrait pouvoir utiliser et maintenir le code ! Et c’était quand même l’objectif ;)

On pourra remercier Vince au passage qui lui trouve du temps à consacrer à ce modeste blog !

Mais je viens de réaliser que cela allait faire quasi un an que j’avais attaqué Ruby / Rails de manière plutôt intensive et qu’un petit bilan s’imposait donc ! Alors je me lance !

Contexte

Un petit coup de contexte, notre startup Autrement édite 2 sites web, Chambres à part et HotelHotel. Le premier est en symfony1.4 et le 2e est en Rails3 suite à une décision prise fin 2009. Pour ceux que ça intéresse, Jérémy avait écrit un billet à l’époque sur ce choix.

A l’époque je m’étais retrouvé un peu seul à tenter vainement de défendre symfony mais j’avais du me résoudre à me lancer dans le grand bain pour la conception d’HotelHotel à laquelle il fallait bien que je participe (bah oué on est un peu que 3 côté techos :p), c’était il y a quasi 1 an !

Je vous préviens, ceux qui me côtoient un peu s’y attendent surement ;), je n’ai pas vraiment changé d’avis : Ruby / Rails j’accroche pas, et de depuis quasi les premières lignes écrites. Et je vais essayer de retranscrire un peu mon ressenti et retour d’expérience.

No révolution

Déjà, aucune révolution, il faut le savoir. Les différences fondamentales sont assez “mineures” dans le sens où ca n’a pas changé grand chose dans ma manière de bosser. En fait, si vous avez fait du PHP et du symfony, vous saurez faire du Ruby et du Rails, mais vous (re)passerez par la case documentation les 6 premiers mois pour trouver les équivalents à vos connaissances PHP/symfony.

Et ça commence du coup mal. Apprendre un langage et un outil en essayant de tenir des “cadences” de production honorables pour son égo, c’est pas simple. C’est même assez compliqué et ça frustre !

Côté bilan, le langage il n’y a pas grand chose à redire si ce n’est ce côté implicite avec lequel j’ai encore maintenant beaucoup de mal, question de goût j’imagine. J’ai croisé un jour un gist avec 2 “versions” d’un même code, l’un en version totalement implicite, l’autre en version totalement explicite (je remets pas la main sur le lien) : pas photo pour moi, le 2e était clairement plus compréhensible sans même connaître Ruby !
Mais les Rubyistes ont choisi le premier… ;)

Après, il est plutôt bien construit, l’api est clairement plus aboutie que PHP, et permet de faire tout autant de chose, et plutôt vite et bien une fois qu’on s’est habitué à sa syntaxe. Il faut être honnête Ruby n’a rien a envier à PHP en tant que langage pur. Mais la réciproque est pas loin d’être vrai. PHP se traine beaucoup de boulet, mais personne nous oblige à les utiliser.

Pas de switch en vue

Du coup pas vraiment de changement suffisant pour me dire que cela vaut le coup de “switcher”. Au contraire même, le problème (oui c’est un problème pour moi) de l’implicite rend toute lecture de code un vrai cauchemar ce qui m’a certainement ralenti et un peu découragé de me plonger à 110% dans le code comme j’aime tant faire. Parcourir des lignes de code que j’ai encore du mal à déchiffrer me décourage un peu. (Et oui désolé, mais moi, j’aime voir mes fins de lignes avec des points virgules !!!)

Pour le framework c’est une autre histoire. A vrai dire, je ne lui trouve pas grand chose pour lui. Attention, il vaut bien symfony 1 qui était ma référence lors de mon lancement dans Rails. Il permet de faire (quasi) tout autant de chose.
Je précise quasi, parce que moi j’ai toujours la vague impression que je suis bridé, certainement parce que je suis encore loin de maitriser les rouages que j’avais pris le temps de décortiquer sur symfony.
Et pourtant c’est déjà sa version3 (qui va avoir un an aussi d’ailleurs). Quand on voit le gap franchi avec symfony1 et Symfony2, la comparaison avec le second ne serait certainement pas à son avantage :p (:troll:)

Et c’est sans doute là que le bas blesse, je me suis retrouvé à repartir de zéro, en me disant que ça je saurais le faire de suite sur symfony, que Rails doit le faire aussi, mais qu’il fallait repasser par la case google. Et au final il le fait mais il ne fait guère plus. Donc peu de vrai “découvertes” et forcément, une petite déception…
Je me retrouve avec 2 couteaux, pas la même forme/couleur, mais le rendu est bien le même, j’arrive à couper mon saucisson sans problème (j’étais à l’apéro au moment d’écrire ces lignes…).
J’aurais préféré me retrouver avec un nouvel outil un peu différent, genre des ciseaux.

Bien sûr, je peux sans doute m’en prendre en grande partie à moi même, je n’ai jamais remis la même énergie que pendant mes 3 années passées sur symfony. Peut-être que je passe à côté de quelque chose ! Jémémy me dirait (et me dira ;)) certainement que oui…

Et puis la communauté me manque ! Je suivais (suit encore en fait ;)) l’actualité, blog, twitter qui tournent autour de symfony. Celle de Rails et même de Ruby est beaucoup plus petite en France et j’ai finalement très vite lâché l’affaire une fois de plus, un peu découragé.

Rajouter à cela, les gems, qui sont très sexy sur le papier mais qui compliquent un peu le côté, je vais mater dans le code comment c’est foutu de ce petit plugin qui rox, bien sûr le fameux RVM qui ne m’aime définitivement pas. On ne parlera pas de Passenger qui a lui aussi ses petits caprices de temps en temps, ou bien le fait qu’il faille redémarrer l’appli pour qu’un changement dans une lib soit pris en compte (mais apparemment que sur ma machine :( )

Des détails me direz vous ! Oui c’est clair, des broutilles auquel on est confronté tous les jours dans notre métier de développeur. Et le changement forcé de mes petites habitudes de bidouilleur PHP n’a pas du arranger les choses.

Je ne rentre volontairement pas dans le côté technique à comparer deux outils qui font leur job. Parce que pour le coup, la différence ne se fait pas là pour moi à mon avis.

Bilan

Au final on peut dire que c’est plus un mauvais feeling et le fait que je sois ravi de symfony et PHP qui font que j’accroche pas. J’ai passé et donné beaucoup de mon temps sur symfony et PHP et je n’ai pas été déçu, finalement je me dis que quelque part, je les trompe un peu … ;)

Et puis Symfony2 est arrivé… J’ai décortiqué les bétas, testé et retesté, lu le code. Et l’excitation de m’en servir grandit chaque jour ! Définitivement, une question de feeling donc. Et aussi parce que j’ai eu l’impression de progresser dans mon métier avec symfony1, et cette même sensation m’envahit quand je vois Symfony2. Ruby / Rails ne m’ont permis que de me diversifier…

Attention, je reste quand même ravi d’avoir pu goûter à ce changement. Ça aura au moins eu le mérite me confronter à autre chose justement, un environnement quasi entier qui diffère ! Je rajoute aussi une corde à mon arc, sait-on jamais hein…

Et ça m’aura permis aussi de me conforter, malgré toute la mauvaise presse qu’il se traine, dans l’idée que moi je l’aime bien mon PHP :p

La conf tombait bien vu que la première Release Candidate de Symfony2 approche à très grand pas, c’était l’occasion d’aborder abondamment ce nouveau framework pour ceux qui n’avaient pas eu encore l’occasion (ou le courage ^^) de se jeter dedans. Les différentes interventions étaient donc principalement orientées autour de 2 axes, Symfony2 en tant que tel, et le passage de symfony 1 à Symfony2 forcément.

Première journée

The lost art of Simplicity

Josh Holmes, un employé de Microsoft, est venu nous parler de la simplicité dans le développement. C’est un bon orateur, la conf n’était pas technique du tout, “juste” de l’ouverture d’esprit. Même si je n’ai globalement pas appris grand chose de nouveau, cette conf Microsoft était bien mieux que celle de l’an dernier, et pas cruciale pour ceux qui sont arrivés en retard (suivez mon regard :D). Un bon début donc.
Voir les slides

Application Security

Un gros morceau du code Symfony2 et une partie toujours très critique d’un framework. C’est Johannes Schmitt qui a reprit le flambeau après la première version du composant par Fabien. On a vu voir un très gros refactoring depuis les premières versions, ca a l’air bien fichu mais mon dieu que c’est devenu énorme comme brique!

Malheureusement on ne peut pas vraiment dire que Johannes est un grand showman comme on a pu en croiser, et il s’est “contenté” consciencieusement de faire une revue des différents mécanismes du composant. Un peu de regrets donc, sur ce gros morceau, peu d’exclu pour ceux qui ont déjà parcouru la doc et le code source.

State of the CMF Project

Lukas, le “lead” du projet est venu nous présenter quels étaient les buts du projet, quelles entreprises étaient impliqués et ce qui avait déjà été fait. L’idée est bonne : axer le développement sur la résolution des problèmes des développeurs (d’où le CMF : Content Management Framework) et réaliser ensuite un CMS complet avec les briques du CMF. Un petit hic : le moteur de stockage des données est basé sur une spec et un soft Java (Jackrabbit), et un backend PHP ne verra probablement pas le jour. Voir mon post sur ce sujet.

Il y aura à mon avis une place pour une alternative plus “conventionnelle”, ie. que les gens normaux et les petites entreprises pourront utiliser.
Vous trouverez les slides sur GitHub.

Apostrophe: a Symfony Powered CMS

Aucun de nous n’était présent, je vous laisse jeter un œil aux slides du coup.

RESTful avec symfony et Symfony

Xavier Lacot et Damien Alexandre de chez Cleverage ont débarqué avec leur Poney pour nous présenter l’implémentation à faire dans les 2 versions de symfony pour faire du vrai bon REST. Présentation complète vu qu’ils sont allés jusqu’à faire quelques benchmarks et nous ont gratinés de quelques slides bien fun ;)
Toute leur présentation sur : http://symfpony-project.org/

Contributing with GIT

GIT était encore là, et c’était encore Scott Chacon qui s’est collé à la lourde tâche de le présenter. Et encore une fois, ce fut avec classe! Scott est vraiment un très bon conférencier (ca se dit? :x) et il est, cette fois, allé plus loin que la simple présentation du SCM, la présentation a également englobé les modes de contributions à GIT. Très complet là dessus et introduisant également le workflow de contribution de github!

Speedy App

Encore un choix à faire, on y était pas. Les slides

Embed sf1 in SF2

Explication d’un cas réel, l’express.fr. Présentation du pourquoi ce choix technique. Le code source reste le plus parlant pour voir l’intérêt. Au final peu de lignes de code à rajouter dans l’appli sf1 pour transformer les réponses en object Response pour sf2 et ainsi bénéficier de la couche Cache de Symfony2.

Un moindre mal pour les applis encore en symfony mais qui voudrait tirer parti de quelques avantages de Sf2.
Voir les slides

Symfony2 : 30 astuces

Noël s’est attaqué à passer en revue, les bonnes pratiques et astuces à garder en mémoire pour les futurs dev Symfony2.
Voir les slides

phpBB4

Sympathique présentation par le lead développeur de phpbb, il y a 10ans déjà. Rétrospective de l’évolution du système de plugins pour aboutir finalement au choix de baser la prochaine version sur Symfony2:
Voir les slides

Forms in sf2

Bernhard qui est à l’origine du composent Form, a pris un peu tout le monde a contre pied en présentant la dernière mouture du composant, qui n’est pas encore mergé dans le master. L’optique ici est de passer les configurations de formulaire via le DIC pour pouvoir tester les contrôleurs sans les forms.
Autre avantage, la partie render est maintenant séparée également. Pour avoir plus de détails sur le pourquoi du comment, hésitez pas à jeter un oeil sur la discussion qu’il a lancé sur la mailing list.

Bon il assure que tout le process d’embed form est plus au point que dans symfony 1, comme beaucoup, tellement traumatisé, je vais attendre de le voir pour le croire :D

Voir les slides

Keynote

Voilà Fabien sur la scène, sans slides prêt à présenter en live Symfony2. Quelques modifications de son installation un peu tardives ont provoquées 15min de debug en live! Quelques sueurs froides, on a même cru qu’il allait renoncer! Mais finalement, c’était tout simplement un vhost mal configuré :)
Sur le contenu, il a voulu montrer que Symfony2 était vraiment simple à appréhender et que le système d’annotation présent via le FrameworkExtraBundle était vraiment “cool”. Donc rien de nouveau en soit, pour tout ceux qui ont déjà eu l’occasion de manipuler la bête.

Perso, j’avoue avoir quelques réticences avec tout ces systèmes d’annotations, très à la mode en ce moment. Peut-être parce que c’est pas natif, ou peut-être parce que j’aime bien avoir les choses à leur place, et pas tout au même endroit. Différente vision certainement!

Deuxième jour

Adopt devops philosophy

Les croissants ont été les plus forts, on y était donc pas:
Voir les slides

Symfony2 from the trenches

Du coup celle là non plus:
Voir les slides

Assetic

L’occasion de découvrir le dernière né des bundles intégré de base dans Symfony2. J’ai suivi de loin la conf pour commencer à mettre au propre ce billet. Mais les slides parlent d’elles mêmes! Assetic, c’est vraiment orienté pour faciliter la vie des developpeurs.
Voir les slides

Application Gruyere

Une nouvelle conf qu’on a pas pu suivre.

HTTP Cache

Fabien revient pour nous parler certainement d’une des features vraiment “militante” (entendre par là, que peu de framework l’utilisent actuellement). Pour lui, le meilleur système de cache est donc de passer par la spécification HTTP qui définit tout un tas de convention pour faire du cache.

Il a donc passé en revue les différents mécanismes de cache via HTTP mais trop de choses à dire donc pas assez de temps pour rentrer dans le code plus en profondeur. Ça promet en tout cas pas mal de prise de tête car du coup la méthode de cache à utiliser revient au développeur! Et même si je reste convaincu déjà depuis pas mal de temps que le cache HTTP c’est bien, être au pied du mur, ça fait un peu peur :p

Solr

J’aurais bien aimé voir la conf, mais finalement faut faire des choix encore et toujours! Une présentation que vous pouvez retrouver ici

Varnish

Un bon tour du propriétaire, fait par un orateur très fun, très blagueur qui m’a donné envie d’aller plus loin! En tout cas Varnish ca a l’air cool, mais surtout si on en a l’utilité en fait…

Quid de mes applications sf1

Marc Hugon a du se contenter de la petite salle pour parler pourtant d’un sujet qui intéressait à mon avis beaucoup de monde. La migrations des applis sf1 vers Sf2. J’ai pas pu rentrer donc faut matter les slides.

Twig

Voir les slides

Symfony2 en pièces détachés

Une grande revue des différents composants présent dans le core de Symfony2 et qui sont utilisables de façon indépendante. Rien de neuf en soit, mais un bon rappel qu’avant de faire son propre composant, ça vaut le coup de jeter un œil à ces composants là!
Voir les slides

Doctrine

Voir les slides

Javascript, Event and Scopes

Une présentation très sympa qui met en lumière les bonnes pratiques à utiliser pour développer à base d’event. Comme l’utilisation du preventDefault() ou encore la différence entre le bubbling et la capture. Suivi ensuite d’un gros rappel sur la portée des variables et les pièges à éviter dans leur nommage.

Sachant que pour de développeurs web, le javascript a toujours été de la “bidouille” c’est toujours bon d’avoir des rappels de bonne pratique, même si encore une fois, rien de neuf sous le soleil.
Voir les slides

BDD : Behavior Driven Development

Voilà une des confs qui a vraiment abordé un sujet trop souvent mis de côté et de très belle façon. Konstantin (plus connu sous le pseudo everzet) a expliquer très simplement en quoi consistait la méthodologie BDD qui n’est finalement qu’une extension du célèbre TDD. Puis a mis en lumières les outils qu’il a développé pour faciliter le travail de chacun.
Clairement une très bonne surprise et une nouvelle étape pour faciliter cette partie du métier de développeur.
Voir les slides

Jeux sociaux et Cloud

Weka qu’on a vu pas mal en tant que sponsor de l’évènement a pu exposer un peu son domaine de prédilection. On attend les slides!

Don’t use a screw when you need a nail

Derrière ce titre, se cachait en fait, Stefan (Skoop) qui a parfaitement résumé ce que tout développeur devrait faire : Chercher les solutions les plus pertinentes en fonction de vos besoins. En faisant un rapide tour des technos non PHP qui répondent à des besoins communs, comme le search, un bug tracker, etc … il a montré que le développement c’est une grande famille et qu’il y a parfois la solution à votre problème pas si loin que ça ;)
Voir les slides

Iscool Story

On attend les slides!

Keynote : one more thing

Musique, effet de lumière, vidéo, Fabien a le mérite de jouer l’auto dérision parfaitement en commençant la keynote par l’annonce de la … Symfony Tablet! Finalement, pour ceux qui ont pas vu la conf retransmise en live apparemment, 3 grandes annonces:

• Symfony2 aura un système d’installer à la wordpress. Il semble aussi simple d’utilisation!
• Symfony2 aura un système de distributions qui embarquera une conf par défaut différente en fonction des cas d’utilisation
• Nouvelle marque! Symfony se dote d’un nouveau ndd, un nouveau site et un nouveau logo : Voir le nouveau site

Rien de révolutionnaire, mais on peut noter l’effort sur le site web, beaucoup plus clair, simple et actuel niveau graphique. Et surtout l’accent mis sur la simplification de Symfony2 auprès des débutants. Fabien a semble-t-il l’intention de “banaliser” au maximum Symfony2 pour montrer qu’on peut faire beaucoup de choses assez simplement avec. Et si c’est pour faire reculer des choses comme joomla, on ne peut qu’espérer que ca fonctionne un peu ;)

Unconférence

Vendredi, Skoop a également mis en place un partie “unconférence”, entendre par là, une conférence un peu informelle. L’idée est super, mais encore une fois, ce ne faisait que compliquer les choix :p

Vous pouvez retrouver le détails des présentations sur le récap de Jonathan

Bilan

Bah c’était cool! Forcément ;)

• Toujours un peu déçu quand on tombe sur une conf qui finalement ne pas plus loin de ce qu’on est déjà allé. Mais fallait bien que les gens qui n’ont pas encore touché le nouveau joujou puissent suivre j’imagine!
• Assez bluffé par l’équipe de traduction en langage de signes. Deux dames pour 4 malentendants (je crois). J’imagine pas le bagage technique qu’il faut pour réussir à traduire ce genre de conférence, chapeau!
• Un peu déçu de pas avoir eu un badge avec un joli tour de cou :x Réduction de coût pour les invités?
• Toujours aussi charmé par l’endroit, si j’avais pu faire mes études dans le coin!
• Merci pour le soleil!
• Le gros point noir, reste finalement le wifi. Une vrai galère pour arriver à la page de login. D’où la publication tardive de ce billet et un niveau de tweet en dessous de ce qui était prévu!

Ravi d’avoir pu rencontrer (ou revu) pas mal de gens, et surtout l’équipe knplabs qui m’a gentiment permis de squatter avec eux :p Bon ya pas mal de tête que j’ai même pas vu voir de loin! Mais ce n’est que partie remise!

Crédit photo : http://www.flickr.com/photos/xavierbriand/5494245376

L’idée dans le tuto d’aujourd’hui est de faire un petit point sur la partie “security” très bien documentée sur le site officiel mais qui change assez des habitudes de symfony 1 et donc semble un peu déroutante au début.

Ce billet est issu de ma propre et récente expérience sur le sujet et sur la branche master de fabien. Les choses peuvent changer ou être inexactes. Dans ce dernier cas, n’hésitez pas à me reprendre via les commentaires ;)

Contexte

Pour l’illustration, je vais simplement partir de la sandbox officielle d’origine configurée sur l’url suivante en local chez moi :

http://sandbox.local

et où je vais vous montrer comment y intégrer votre admin avec un formulaire d’identification sur l’url suivante :

http://sandbox.local/admin/

L’utilisateur sera géré directement via la config, pas de bdd, on veut quelque chose de très simple et rapide à mettre en place.

Première chose à comprendre dans une application Symfony2, il n’y a plus qu’une application… Oui hein, ça parait fou dis comme ça :D Toute la séparation se situe au niveau des bundles, chacun d’eux pouvant embarquer des modèles, controllers, vues différentes, tout en pouvant communiquer avec les autres bundles. Fini les galères pour faire des liens entre un backend et un frontend !

Pour notre admin, nous allons donc générer un nouveau bundle dans notre application via la commande :

php app/console init:bundle Application/AdminBundle

On se retrouve donc avec un controller basique dans ce bundle qui sera la base de notre admin. Première chose à faire, l’activer dans le fichier app/AppKernel.php via la méthode registerBundles.

Mise en place url admin

On va maintenant tenter d’y accéder via l’url /admin/

Pour ça, c’est très simple ! On va modifier notre fichier routing.yml (ou xml ou php hein, mais moi j’aime bien le yml ! ) comme ceci :

#path:app/config/routing.yml
 
homepage:
    pattern:  /
    defaults: { _controller: FrameworkBundle:Default:index }
 
hello:
    resource: HelloBundle/Resources/config/routing.yml
 
admin:
   resource: AdminBundle/Resources/config/routing.yml
   prefix: /admin

et du coup créer le fichier de routing de notre nouveau AdminBundle. Pour ça, on va faire quelque chose de très simple aussi:

#src/Application/AdminBundle/Resources/config/routing.yml
admin_homepage:
  pattern:  /
  defaults: { _controller: AdminBundle:Default:index }

Et par magie, maintenant, si vous accédez à l’url :

http://sandbox.local/admin/

Vous obtenez le mot “Hello” qui n’est d’autre que la vue par défaut qui a été générée par la commande init:bundle
Pour pas se perdre, on va modifier la vue, pour y indiquer le mot admin, ca sera plus clair.

Sécuriser l’url d’admin

2e étape, comment sécuriser tout ça pour ne pas laisser tout le monde accéder à votre admin. Pour ça il y a en fait plusieurs solutions.

• Sécuriser toutes les urls de votre application, en autorisant les connexions anonymes partout, sauf dans votre admin
• Sécuriser toutes les urls de votre admin seulement

La 1ere a l’avantage de faire écrire très peu de ligne de config, mais honnêtement, je ne sais pas s’il y en a une de meilleure que l’autre, donc je présente la première dans ce tuto, mais je vous met le code de la deuxième à la fin. Elles font sensiblement la même chose.

On va donc se lancer dans la config du component security. Pour ça, on se retrouve dans notre config.yml pour y ajouter un provider, qui sera en fait le compte utilisateur de notre admin.

#app/config/config.yml
security.config:
  providers:
    admin:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }

Nous voici avec un compte “monadmin” identifié grâce au mot de passe “monpass” qui sera crédité de l’autorisation “ROLE_ADMIN” (pour pourriez mettre TOTO à la place de ADMIN, ca changerait rien, par contrel mot ROLE est apparemment obligatoire)

Pour l’instant, ca ne change rien. Définissons maintenant une règle firewall ! Le mot utilisé pour définir ce nouveau service fait sourire j’avoue, en fait il s’agit de définir des règles de sécurité pour des motifs d’urls.

On reste dans notre config.yml qu’on enrichit comme ceci:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN  }
 
  firewalls:
    admin:
      pattern: .*
      http_basic: true

Et là, vous obtenez normalement une demande d’authentification HTTP sur tout votre site. Ok! Maintenant, on va autoriser des connexions anonymes, c’est à dire qu’on ne va pas forcer les gens à se connecter:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      http_basic: true
      anonymous: true

Maintenant, voyons voir pour mettre en place un formulaire plus conventionnel (et il me semble plus secure si bien fait, mais à confirmer).

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true

Ici on a changé le mode d’authentification pour celui d’un formulaire classique, grâce à l’option form-login

Maintenant, on va verrouiller l’accès à notre admin. Pour ce faire, on va demander une autorisation pour notre url /admin:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true
 
  access_control:
      - { path: /admin/.*, role: ROLE_ADMIN }

Et maintenant, si vous essayez d’accéder à l’url :

http://sandbox.local/admin/

Vous êtes redirigés vers l’url:

http://sandbox.local/login/

qui se termine en 404! Jusqu’ici c’est normal.

Symfony2 par défaut, utilise 3 urls pour la gestion de l’authentification :

• login
• login_check
• logout

Nous allons donc les rajouter dans notre routing.yml tout simplement. Attention de bien les mettre au début, histoire d’éviter tout conflit avec une autre de vos règles.

_security_login:
  pattern: /login
  defaults: { _controller: AdminBundle:Default:login }
 
_security_check:
  pattern: /login_check
 
_security_logout:
    pattern: /logout

Le login a besoin de nous pour constituer le formulaire d’identification, les 2 autres doivent seulement exister ! Les patterns des urls peuvent varier, mais il faut alors donner les nouveaux paths dans le config.yml, nous verrons ça plus tard.

Maintenant, si nous accédons à notre admin nous avons bien sûr l’exception suivante:

Method "Application\AdminBundle\Controller\DefaultController::loginAction" does not exist.

On la crée donc:

<?php
// src/Application/AdminBundle/Controller/DefaultController.php
 
namespace Application\AdminBundle\Controller;
 
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\Security\SecurityContext; // à rajouter
 
class DefaultController extends Controller
{
    public function indexAction()
    {
        return $this->render('AdminBundle:Default:index.php');
    }
 
    public function loginAction()
    {
       // get the error if any (works with forward and redirect -- see below)
      if ($this->get('request')->attributes->has(SecurityContext::AUTHENTICATION_ERROR)) {
          $error = $this->get('request')->attributes->get(SecurityContext::AUTHENTICATION_ERROR);
      } else {
          $error = $this->get('request')->getSession()->get(SecurityContext::AUTHENTICATION_ERROR);
      }
 
      return $this->render('AdminBundle:Default:login.twig', array(
          // last username entered by the user
          'last_username' => $this->get('request')->getSession()->get(SecurityContext::LAST_USERNAME),
          'error' => $error,
      ));
    }
}

Donc là, j’ai simplement récupéré le code fourni dans la doc officielle, pas de mystère non plus. Et voici la vue correspondante :

<form action="{% path "_security_check" %}" method="post">
 
  {% if error %}
	<div class="notification error png_bg">
		<div>
			{{ error }}
		</div>
	</div>
  {% endif %}
 
  <p>
      <label>Username</label>
	<input class="text-input" type="text" name="_username" value="{{ last_username }}" />
   </p>
   <p>
      <label>Password</label>
      <input class="text-input" type="password" name="_password" />
   </p>
   <p id="remember-password">
      <input type="checkbox" />Remember me
   </p>
 
   <p>
	<input class="button" type="submit" name="login" value="Sign In" />
   </p>
</form>

Là aussi, très basique mais ça vous donne l’occasion d’essayer twig ;) Ce qui compte pour le coup, c’est surtout les attributs name des input (_username et _password), et de rediriger vers /login_check

A noter que l’utilisation du tag path dans la dernière version de twig n’est plus d’actualité. C’est désormais une fonction, donc à utiliser comme ceci {{ path(‘_security_check’) }}

Alors oui, il faudrait un layout et tout, mais bon, on va aller droit à l’essentiel.

On retrouve bien notre formulaire de login maintenant, si on essaye d’accéder à notre admin ! Encore mieux, si on essaye de s’authentifier, avec le couple login/password défini au début, on obtient notre page “admin!” Et il suffit d’ajouter une dernière ligne à notre config, pour ajouter le listener manquant sur le /logout :

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true
      logout: true
 
  access_control:
      - { path: /admin/.*, role: ROLE_ADMIN }

Et maintenant, vous pouvez vous déloguer sur l’url :

http://sandbox.local/logout

Histoire d’illustrer un peu plus, voici une autre config qui fonctionne aussi et qui permet de ne sécuriser que l’admin:

security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_TOTO }
 
  firewalls:
    admin: { pattern: /admin/.*, form_login: true }
    login: { pattern: /login, anonymous: true, form_login: true }
    login_check: { pattern: /login_check, anonymous: true, form_login: true }
    logout: { pattern: /logout, form_login: true, logout: true }
 
  access_control:
       - { path: /admin/.*, role: ROLE_TOTO }

Il y a bien sûr, beaucoup de tuning possible, pour encoder le password par exemple, mais maintenant qu’on a la base, je vous laisse lire vraiment la doc entière cette fois-ci ;)

[s|S]ymfony : un homme

[s|S]ymfony c’est un homme, une vision : Fabien Potencier. Il y a certes une belle communauté autour, Kris qui s’occupe des release de la 1.4 notamment, Jon qui était embauché par Sensio pour Doctrine, mais c’est Fabien qui a toujours dirigé le développement du Framework. Depuis quelques temps déjà, Fabien est passé sur le développement de Symfony2, et a donc arrêté tout nouveau développement sur symfony 1. La conséquence immédiate est l’absence de quelconque nouveauté depuis plus d’un an sur symfony 1, et ce encore pour plusieurs mois.
Alors oui on nous explique que symfony 1.4 marche, certes, mais il continuera donc de se trainer ses défauts jusqu’à la fin de sa vie : Admin generator qui est là pour faire bien, forms imbriqués qui sont le cauchemard de tout développeur symfony, … On va aussi vous dire : mais t’as qu’à contribuer (oui vous savez, la réponse ultime de toute discussion open source non constructive) ! Le souci c’est que généralement quand on utilise un Framework, c’est pour gagner du temps, pas pour passer son temps à le développer (je me place du point de vue utilisateur, le cas spécial du contributeur core n’est pas traité ici). On peut contribuer avec des plugins certes (je suis le premier à le faire dès que je peux), mais pour moi la gestion des forms imbriqués devrait relever du Framework, pas de plugins.

Ma vision des choses

Donc si on dresse le tableau après plus d’un an de stagnation de symfony 1 :

• symfony 1 va stagner pendant toute la durée de sa future vie (officiellement novembre 2012)
• pour avoir des nouveautés Symfony, il faudra attendre Symfony2 qui est prévu, au plus tôt, Mars 2011
• Symfony2 en mars ne sera qu’une première version, donc loin de toutes les subtilités et fonctionnalités que peut avoir symfony 1

Vous allez me dire que ce tableau n’est pas très réjouissant, j’en conviens. Ça n’empêche nullement de démarrer des projets sur symfony 1.4, je le fais encore moi même, mais je pense que ça encourage à se poser les bonnes questions. Tiens, peut être qu’il existerait quelquechose qui pourrait combler mon manque, ma frustration en attendant Symfony2 ? Peut être que je pourrais avoir tout ce que symfony 1 m’apporte autre part, tout en utilisant quelquechose qui n’est pas voué à stagner ? Et si en plus je pouvais apprendre de nouvelles choses, ça serait top !

Django, une ouverture d’esprit ?

On aime tous évoluer, apprendre (enfin j’espère), se remettre en question … Mais beaucoup d’entre vous ont aussi des objectifs de rentabilité, de sureté vis-à-vis du client. C’est pourquoi utiliser votre client comme “même-pas-alpha-testeur” de Symfony2, ça reste encore très risqué et difficile à faire passer à votre direction.
Il existe d’autres Frameworks, d’autres langages que le PHP, c’est peut être l’occasion, en attendant Symfony2, de les tester sur des projets à faible risque ? En voici quelques un que j’aimerais tester personnellement : Play Framework en Java, Django en Python et Rails en Ruby. Si vous voulez vraiment avoir un avant goût de Symfony2 et que vous êtes prêts à vous attaquer à la bête, allez voir du côté de Spring en Java. Même si vous ne les testez que sur un projet, prenez le temps de le faire. Croyez moi, ça vous permettra de prendre du recul, et ça c’est toujours bon !

Pour ma part, je l’ai fait pour Django, et j’en suis très content. On retrouve vite ses petits par rapport à symfony et ça permet de faire un contrastif très intéressant avec symfony. C’est là qu’on se rend compte qu’il arrive, des fois, que l’herbe soit aussi verte ailleurs (mais pour ça, il faut aller voir).

Crédit photo : http://www.flickr.com/photos/clementlivolsi/4566165441/

Le weekend dernier, 29 Mai 2010, avait lieu le Web Event #2 organisé par La Ferme du Web. J’ai donc quitté ma région nantaise pour me rendre à Lyon afin de participer à l’évènement mais aussi revoir quelques connaissances ;)

En attendant les photos, les discussions détaillés et les vidéos, voici un bref résumé de ce petit weekend lyonnais.

Vendredi 28 Mai 2010

Il est à 21h05 quand mon train de nuit (oui savatte, il roule la nuit et il s’arrête même des fois ^^) quitte la gare de Nantes direction Lyon.

Quelques épisodes de HIMYM et beaucoup de ronflements (l’inconvénient des trains couchettes) plus tard, me voici à Lyon, ville que je n’avais presque plus vu depuis mon départ il y a 5 ans.

Samedi 29 Mai 2010

Il est 6h45 quand je sors du train, direction chez piouPiouM et Le Piaf Fou pour allez prendre le petit dej !! Vers 8h00 j’arrive a destination (on passera l’épisode où je me suis perdu j’ai visité la ville :p ) Des retrouvailles très sympa autour d’un bon petit dej.

Après quelques heures de discussion et une bonne douche, il est temps de partir à Pardieu pour rejoindre un ancien collègue, kewix pour manger ensemble. Après 2 bières, kewix arrive enfin et nous allons au Rouge Tendance où je prendrais un magnifique Bison Burger :)

Une fois ce succulent repas terminé, kewix nous invite à un flashmob sur la place des terreaux. Ce petit interlude terminé, l’heure du rendez-vous approche, et pour combler les quelques heures avant le début du Web Event #2, rien de ne vaut une bonne bière en terrasse. Très vite rejoint par savatte puis Karedas (il me semble), les discussion s’enchaînent et il est déjà 18h, l’heure de partir.

Quelques minutes plus tard, nous arrivons au Gotha, bar du 1er arrondissement de Lyon ou déroulera la soirée.

Accueil

Le bar n’est pas dur à repérer, une vingtaine de personnes sont déjà devant à discuter. Avec kewix, on récupère notre badge, le livret de contact et le tee-shirt avant de ressortir discuter avec les personnes présentes. Beaucoup de premières rencontres et notamment ubermuda, natif de la région nantaise et qui était au lycée avec mes frangins. Que le monde est petit ^^

Speed Meeting Pro

Il est déjà 19h et la soirée commence par 2 sessions de 30 min de speed meeting pro. Malgré la durée un peu courte, de très bonnes rencontres lors de ces sessions avec notamment mosamich créateur de MosaLingua et Schoolhead, étudiant un peu geek sur les bords :)

Le speed meeting pro terminé et en attendant la suite, petite virée au bar pour prendre une mousse, avec entre autre mosamich et David de Reportages Photos.

Cocktail dînatoire

Nous avons le droit ensuite à un petit cocktail dînatoire avec quelques mots des sponsors. C’est l’occasion de faire de nouvelles rencontres et notamment une très sympa avec Sylvain de My EShop avec qui on fera une petite virée au bar d’à côté pour voir la fin de la finale du Top14 et parler e-commerce.

Les cadeaux

La suite de la soirée se poursuit avec un tirage au sort pour gagner quelques lots, et c’est aussi pour moi l’occasion d’enfin réussir à trouver rkueny pour discuter un peu avec lui. La première chose que je lui ai dis il me semble, c’est que je ne gagnerais rien au tirage au sort, comme d’habitude (et visiblement comme frymde ^^). Je n’ai effectivement rien gagné mais grâce à piouPiouM j’ai eu le livre Plus loin avec Symfony 1.3 & 1.4 qu’ubermuda aurait pu me dédicacer ;)

After et after d’after !

Tirage au sort fini, la fin de soirée approche, encore quelques discussions et c’est l’after qui commence avec beaucoup de monde et notamment à ma table les gars de Scopart, très sympa et avec qui nous avons eu des discussion intéressantes.

On enchaîne avec l’after de l’after en compagnie des derniers participants mais aussi des organisateurs Ouark et Djo.

Fin de la soirée vers … je ne vais pas vous mentir, je ne me souviens plus trop de l’heure mais il devait être près de 4h quand on est arrivé chez piouPiouM et Le Piaf Fou :)

Dimanche 30 Mai 2010 et Lundi 31 Mai 2010

Un dimanche tranquille chez un pote à Caluire avant de repartir le lundi matin.

Au revoir Lyon et surement à l’année prochaine en espérant cette fois venir avec Vincent et Tim ^^

P.S: désolé à ceux que j’aurais oublié, j’ai eu du mal à retenir tous les noms/pseudos.EAVB_JFBPMSIYLC

Maintenant que c’est fait, nous allons parler ici d’un des aspects de symfony les plus intéressant, mais aussi d’un des moins bien documenté. Pas que les forms “basiques” ne soient pas documentés, mais dès que vous voulez faire autre chose qu’un form qui représente tel quel (ou presque) un objet de la base de données, ça se complique un peu.

Je vais essayer de vous faire un petit tour d’horizon de ce qu’on peut faire avec les embedded forms.

Les forms, c’est de la POO

Vous allez me dire que tout symfony est de la POO (Programmation Orientée Objet), et vous avez raison. Mais on peut utiliser symfony sans être un expert de la POO (voire sans vraiment savoir ce que c’est), en suivant Jobeet et en comprenant que executeIndex inclut le template indexSuccess.php en cas de succès. À partir de là, on est le roi du monde.

Enfin, du monde, moins les forms. Car les forms sont – à mon sens – la partie de symfony qui est à la fois utilisée par tous les utilisateurs de symfony, et à la fois très orientée objet (les factories sont par exemple beaucoup moins utilisées …). Du coup, ça mérite quelques explications.

Tout le monde n’est pas doué en POO

Certes tout le monde n’est pas doué en POO, professionnel ou pas d’ailleurs ;) À l’inverse de JAVA où les programmeurs n’ont pas vraiment le choix, la POO est récente dans PHP et certains l’ont découvert comme un cheveu sur la soupe.

L’impression que l’on a quand on essaye de changer le comportement des embed form c’est : mais où est-ce que je peux bien faire ce que j’ai envie de faire? doBind, doUpdateObject, saveEmbeddedForms, … les choix sont multiples.

Et pour cause, les forms utilisent énormément l’héritage, et disposent donc de moultes méthodes que l’on peut surcharger, sans que ce ne soit vraiment documenté autre part que dans l’API. Si on ne comprend pas les principes de base de la POO, les forms sont une vraie galère (déjà que quand on les comprend …).

Petit rappel sur la POO sur developpez.com : Consultez au moins la partie sur l’héritage pour ceux qui sont largués.

Principales étapes de gestion des formulaires

Il faut quand même que vous ayez quelque chose à l’esprit, il y a pour moi deux principales étapes quand vous souhaitez traiter un formulaire qui vient d’être soumis :

• 1 ère étape : lier les valeurs qui sont récupérées dans la requête à l’objet Form (c’est à dire les recopier en s’assurant qu’elles sont valides et nettoyées)
• 2 ème étape : Une fois les valeurs recopiés dans le $values du formulaire (qui n’est en fait qu’un tableau de valeurs nettoyées), réaliser un traitement dessus ou sur l’objet qui en découlera (nous verrons cela par la suite)

Il est toujours bon de se demander ce que l’on veut faire exactement : agir sur les valeurs qui seront recopiées et validées dans notre form, ou alors agir sur les valeurs nettoyées et recopiées, avant qu’elles ne soient sauvegardées en base.

Première étape

Lors de la première étape de liaison/validation/recopie des valeurs de la requête dans votre formulaire (votre objet Form), vous pourrez agir sur les données avant qu’elles ne soient passées dans les validateurs, ou alors une fois qu’elles sont passées dans les validateurs.

Vous pourrez faire votre bourrin : enlever des parties de votre formulaire de la requête en vous basant sur certaines valeurs soumises.
Par exemple enlever tout un formulaire embarqué, si certaines valeurs ne sont pas saisies (c’est l’exemple qu’on trouve pas mal sur le web d’ailleurs).
Petit souci : les valeurs de la requête n’auront pas été validées/nettoyées par les validateurs, vous vous exposez donc à quelques soucis (dans le style le gars qui n’aura rempli que des espaces dans un champ texte, faudra penser à faire vous même le trim avant de vérifier la valeur …).

Deuxième étape

Lors de la deuxième étape, c’est ici que vous devrez effectuer les traitements concernant votre logique métier à proprement parler. La première étape s’est occupée de vous donner accès aux valeurs dans votre formulaire (via le tableau $values), maintenant que c’est fait vous pouvez jouer avec.

Vous voulez mettre à jour un objet qui dépend de celui que vous allez sauvegarder automatiquement, vous souhaitez insérer votre objet dans un nested set, etc etc … C’est dans cette étape que vous ferez ça.

Je sépare sciemment le processus en deux étapes, après vous pouvez le voir autrement. Les étapes étant chaînées, vous pouvez les mélanger et faire un peu de business logic à la fin de l’étape 1 par exemple, mais essayez de rester constant partout dans votre code, où vous ne saurez plus où aller voir quand il y a un souci.

Étude de cas

On va prendre ici un cas tout simple, celui d’un formulaire auto-généré par doctrine à partir d’une table de votre modèle.

Appelons notre modèle PetitSuisse. On aura donc une classe nommée PetitSuisseForm.class.php dans lib/form/doctrine/

On va vite fait faire le parcours d’héritage de cette classe :
PetitSuisseForm => BasePetitSuisseForm => BaseFormDoctrine => sfFormDoctrine => sfFormObject => BaseForm => sfFormSymfony => sfForm (ouf)

Même si quelques unes de ces classes sont vides, on comprend que ça puisse devenir un peu dur de savoir où chercher. Alors oui l’abstraction c’est bon mangez en, mais ça engendre une complexité de lecture du code non négligeable.

Les classes qui sont “à vous” et donc dans lesquelles vous pourrez surcharger des méthodes sont PetitSuisseForm et BaseFormDoctrine.

La première vous permettra de surcharger une méthode relative au formulaire du modèle PetitSuisse, la deuxième vous permettra de surcharger de manière plus globale (chacun des forms auto-générés par doctrine héritant de BaseFormDoctrine). Je parle ici de symfony 1.3+, vous n’aurez pas toutes ces classes dans les versions précédentes.

On va maintenant parler des principales méthodes que vous aurez (peut être) à surcharger. Il en existe d’autres, si celles ci ne vous vont pas, lisez le code de symfony ;-)

1 ère étape (liaison)

doBind(array $values)

C’est la méthode qui va faire appel aux validateurs pour nettoyer les valeurs de la requête avant de les placer dans le tableau des valeurs. Ce sont ensuite sur ces valeurs nettoyées que nous travaillerons. Vous pouvez ici toucher aux données brut de pomme qui sortent directement du formulaire envoyé, sans traitement préalable.

2 ème étape (sauvegarde)

doSave($con = null)

C’est cette méthode qui sera appelée (par save() ) lorsque vous demandez la sauvegarde de votre formulaire. Elle se charge de mettre à jour votre objet avec les valeurs du form en appelant updateObject (qui appelera doUpdateObject que nous verrons par la suite).
Si vous souhaitez changer le processus de sauvegarde, ajouter par exemple l’appel d’une vos méthodes à chaque sauvegarde du formulaire (pourquoi pas garder trace dans un fichier de toutes les sauvegardes de vos formulaires), c’est ici que vous devez le faire.

processValues($values)

C’est ici que vous pouvez toucher les valeurs qui ont été nettoyées par les validateurs, avant qu’elles ne soient passées à la méthode updateObject (que nous verrons par la suite). Je n’ai pas de traitement particulier en tête, mais l’idée est là : modifier des valeurs avant qu’elles ne soient utilisées pour mettre votre objet à jour.

doUpdateObject($values)

C’est cette méthode que vous devrez surcharger si vous voulez réaliser une opération spéciale sur votre objet avant qu’il ne soit enregistré dans la base.
Par exemple, si vous voulez insérer cet objet à la fin d’un NestedSet, vous ferez ça ici. Le $values passé en paramètre est un tableau contenant les valeurs du formulaire, une fois qu’elles ont été nettoyées/vérifiées par les validateurs.

updateObjectEmbeddedForm($values)

Je pense qu’elle veut bien dire ce qu’elle veut dire. Elle va se charger d’appeler la fonction updateObject de chaque formulaire embarqué. Vous voulez agir sur le traitement des données par vos forms embarqués ? C’est par ici !

saveEmbeddedForms($con = null, $forms = null)

Allez la petite dernière pour la route : elle se charge de la sauvegarde de chacun des objets de vos forms embarqués. Fabien Potencier en donne un exemple de surcharge dans le livre “More with symfony”

Exemple d’utilisation

C’est bien beau de parler, mais un peu de concret ne fait pas de mal.

Vous trouverez un bon exemple pour comprendre le comportement des forms sur le blog de n1k0 dans son article Embedding Relations in Forms with Symfony 1.3 and Doctrine. Certes c’est en anglais, mais le code est universel ! Si vous avez des bons articles en français je suis preneur aussi.

Il existe maintenant la méthode embedRelation() et le plugin de Daniel Lohse ahDoctrineEasyEmbeddedRelationsPlugin qui font ça tout seul. Mais c’est toujours bien de comprendre ce que l’on fait ;-)

Conclusion

Je vous ai fait un petit tour d’horizon des principales méthodes que vous pouvez surcharger dans votre formulaire. Comme je l’ai dit plus haut, ce n’est pas une liste exhaustive, mais vous devriez avoir de quoi vous amuser.

J’ai juste essayé de voir tout cela d’une manière un peu plus globale et de ne pas proposer un n-ième exemple de code pour les formulaires embarqués.

Mais avec tout cet attirail, gardez à l’esprit que votre code d’action ne doit pas dépasser le classique Bind > Save! Ce qui est au traitement de votre formulaire, reste dans votre formulaire! Enjoy!

Crédit photo: http://www.flickr.com/photos/fromeyetopixel/2470999873/

Après, vous avoir résumé à notre façon, les 2 jours, il nous semblait pertinent de vous faire un petit topo des coulisses, histoire de vous mettre encore plus dans l’ambiance et vous donner envie (ou pas) de nous y retrouver la prochaine fois!

L’endroit

La conférence, était à Paris, à la Cité Internationale (côté porte d’Orléans donc), facilement accessible en transport en commun – métro, tram et rer pas loin – comme la précédente session en 2009. Seule différence, la salle.

À l’arrivée le premier jour, vous montrez patte blanche et on vous remet votre badge, votre joli tour de cou et un petit sac de pub, stickers, tshirt et autre tournevis (sisi, un tournevis yahoo :p). Il ne reste plus qu’à pousser la porte de l’arène. Juste derrière, on retrouve les stands des livres de Sensio, des éléphants PHP en peluche et autre goodies.

Pour le coup, on était à l’espace Adenauer (pour ceux qui connaissent l’endroit). Donc une grande salle avec gradin entouré d’un U, avec tables, chaises et quelques prises électriques. Prises qui ont du coup chauffées énormément, et ce fut un peu la guerre pour recharger son notebook chéri – heureusement que la majorité était des macs avec des autonomies digne de ce nom, mais je m’égare.

Du coup, il était possible d’aller se détendre sur les côtés si une conférence ne vous emballait pas, ou si vous aviez une urgence à traiter, un billet de blog à écrire et j’en passe. C’est toujours sympa. Bon du coup, les conférences avec peu de succès étaient en direct concurrence avec le bruit environnant, mais rien de dramatique.

Le ravitaillement

Mais le principal, derrière l’écran de projection, le ravitaillement ! Mini croissants, pains au chocolat, truc aux raisins pas bon, jus d’orange, café, thé, le tout à volonté :p Bon forcément, le café ne fait pas long feu, donc mieux vaut ne pas arriver trop tard.
C’est d’ailleurs le point qui aura marqué beaucoup de monde à voir les tweets passer sur le sujet. Moralité, les geeks boivent du café, étonnant non ?

A midi, branle-bas de combat: Les lunchs bags arrivent ! En général, vous pouvez aller vous détendre 10min, en laissant la première vague se battre pour les premiers, de toute façon, il y en toujours plus que pas assez :p On se demande quand même, comment Fabien faisait pour être le premier servi, mais on va dire qu’on a rien vu ;)

Donc le minimum syndical, pour le repas – offert donc, enfin offert, compris dans le prix dirons nous ;) -, un sandwich – au choix parmi 4 ou 5 différent tout de même -, du saumon, au jambon, en passant par les classiques poulet, fromage, accompagné d’une bouteille d’eau et d’une part de tarte.
A noter, que la tarte aux poires de Mercredi m’aura beaucoup plus emballé que celle aux pommes de Mardi, mais question de goût :p

Le confort

En tant que geek, en temps normal, on n’est pas difficile, pourvu qu’on puisse se connecter en wifi. C’était le cas, et après une petite frayeur en arrivant Mardi, il s’est avéré qu’il a plus ou moins tenu le coup ensuite.

Pour s’asseoir, on avait le choix des chaises devant l’estrade ou les fauteuils des gradins, genre petit cinéma de quartier. Malheureusement, même si on trouve ça sympa au début, la mousse des sièges datant certainement, elle fini par se tasser – en y restant plus de 3h d’affilée, forcément – et donnait l’impression d’être assis sur une planche de bois.

Certes on venait pas pour le confort, mais rajouté à l’espace assez étriqué pour chaque fauteuil, c’était pas le luxe non plus :p
Heureusement la conférence a tenu ses promesses, ce qui nous permettait de se focaliser sur autre chose – peut-être était-ce prémédité.

Les orateurs

On a eu le droit à une belle brochette d’orateurs, tous avec des présentations en général rondement menées et bien calés sur leur sujet. Évidemment, pas simple pour les pays latins de rivaliser avec les accents américains de John ou Dustin, mais dans l’ensemble, je pense que tous ont été compris. Alors certes certains puristes ont critiqué l’accent de ubermuda, c’était juste un moyen d’apporter un peu de French touch à cette conférence ;)

On a pu apprécier, pour beaucoup, leur capacité à captiver leur auditoire, entre les slides joke, les effets musicaux ou les petites phrases échappées entre 2 slides, c’est resté très cool et dans une bonne ambiance.

Pour ce qui est de l’organisation, Hugo s’est occupé du passage de micro et d’écourter les sessions qui commençaient à dépasser, permettant un planning presque respecté.

Niveau transition, on avait 5min de break entre chaque intervention, pas de quoi aller fumer une clope, et 1 pause de 15min toutes les 2 heures. Un bon rythme, même si ca représente un gros effort de concentration, c’est toujours plus simple quand on est intéressé par le sujet.

Rencontres

Pas simple de ce côté, car énormément de monde et un planning assez serré, pas la possibilité de rester tard dans la soirée. En rajoutant à ça, la volonté de couvrir l’évènement sur le blog. J’ai pas été super dispo.

Bon on a réussi à accrocher ubermuda, toujours mieux que rien :p

Photos

Forcément, on a la chance d’avoir des photographes amateurs dans ce genre de réunion, je vous laisse jeter un oeil aux photos tagguées sflive2010 sur flickr.

Conclusion

Finalement seul détail qui m’aura marqué, c’est surtout le manque de poubelles ! Il me semble que j’en ai aperçu 2, dans la zone de ravitaillement, pas forcément très grandes. Ce qui fait – à tort ou à raison – que le sol près des sièges a été annexé parfois par les gobelets en plastique. Bon on reste des geeks me direz vous.

Matinée

Okapi

Bon, on avoue, on a un peu zappé cette conférence, histoire de gagner un peu plus de temps de sommeil pour tenir sur la durée, et en profiter pour mettre au propre le billet d’hier. On a juste retenu qu’ils utilisaient le Dependency Injection Container des components symfony.

Mais vous pouvez retrouver les slides.

Optimisation PHP

Un tour complet à coup d’exemple de opcode, intéressant même si au final ce sont toujours les mêmes choses qui sont redites, très génériques. Je me tends à croire qu’un jour on aura un vrai cas concret dans ce genre d’intervention.

Et puis surtout, quand on utilise un framework, on a plus à gagner, à bien utiliser le framework qu’à optimiser une boucle.

Mais on a réussi à avoir quelques tips supplémentaires pendant la séance de questions :

• La pré incrémentation est plus rapide que la post incrémentation
• Toujours privilégier la boucle while à une boucle for
• Bannir les relations parent/enfant – L’enfant pointe sur le parent et inversement. Pas bon pour la mémoire

Voir les slides
Et pour aller plus loin dans le sujet, une ancienne présentation de Fabian Lange.

Git introduction

Une des premières sessions Show Time, où Scott Chacon y est allé franco pour présenter Git, à une assistance majoritairement SVN.
Une petite autopromo : rapidité, travail offline (sauf pull et push) et puissance du système de branches ont suffit à mettre le doute dans la tête de beaucoup, à ce qu’on pouvait lire sur twitter après coup.

Il a ensuite donné le lien d’une librairie pour contrôler git depuis PHP (glib) et a su répondre à la principale question:

Un équivalent de SVN externals?

Bien sûr, git uses submodules, mais il faut les mettre à jour à la main (donc 2 commandes au lieu d’une pour mettre à jour, ça reste raisonnable)

Voir les slides

Zend Framework

Est arrivé, celui qui s’est présenté comme “N’est pas l’ennemi”, le lead developer du Zend Framework.
Il a rappelé combien étaient nombreuses les librairies et composants développés et combien il était facile de les inclure dans symfony. Ca m’a d’ailleurs fait penser, que je ne regarde sans doute pas assez chez eux, quand j’ai besoin d’une librairie externe.

Voir les slides
Et Matthew a ensuite fait un debriefing son intervention sur son blog.

Aprem

Implementing Symfony CMS

La première touche hispanique de la conférence, qui nous a rappelé combien symfony était vraiment international. Marcos, nous a donc expliqué pourquoi avoir choisi symfony pour développer les CMS de leur client et l’approche qu’ils ont eu pour le réaliser.

Pas de gros scoop, ni d’exemple super concret mais une approche intéressante et surtout, tirée d’une vrai expérience dans le domaine.

Voir les slides

Event System

Deuxième intervention de Dennis sur un des mécanismes sans doute le moins utilisé dans la panoplie Symfony, les events. Après avoir repris, ce qu’on peut trouver sur Symfony-Project, il a démontré pourquoi le couplage trop fort, c’était le mal - et donc les events le bien (ou le mal aussi, voir ci-dessous).

Un petit sondage fait sur twitter, a montré combien les possibilités étaient larges. Mais aussi qu’on pouvait en faire tout et n’importe quoi – Merci ubermuda pour la démonstration :p.
Ce qui nous a valu l’expression “Events, No silver bullet!” – Entendre par là, que ce n’est pas la solution à tout.

En résumé, un event s’utilise pour du “couplage optionnel”, sinon ça revient à avoir un couplage fort également.

Des questions assez peu pertinentes dans l’ensemble, comme quoi, c’était pas clair pour tout le monde les events, la conf était donc nécessaire contrairement à ce qu’on pouvait lire sur twitter.

Voir les slides

Symfony in the cloud

Kris, de la core team, avec cette présentation aura remporté le prix des meilleurs transitions et de la slide la plus Hollywoodienne, avec une démo en temps réel de la création d’un nuage – musique de circonstance pour l’occasion – où il a réussi un tour de force en rajoutant un nuage en arrière plan de son nuage!
Le public était conquis.

Plus sérieusement, il a pris comme support son site nebul.us, pour montrer comment interconnecter Symfony avec différents environnement à base de nuage, 3 serveurs Mysql – 1 Master, 2 Slaves – n apache, S3 pour le stockage.

De très belles démo de code pour bénéficier des nouvelles possibilités d’extension de Doctrine 1.2 – à voir dans les slides – entre autres mais aussi d’utilisation de composant Zend.

L’effet démo ne l’aura au final pas épargné lui aussi, une tentative de release en direct de son plugin pour gérer les couples Master/Slave et un beau fail quand il est revenu sur la page d’accueil après qu’il se soit reloggué suite à l’expiration de sa session sur symfony-project :D

À noter que cette présentation aurait pu ne pas avoir lieu si Vince n’avait pas sauvé la mise, en sortant un adaptateur dvi ancienne génération pour le prêter à Kris :p

Voir les slides

Debug Symfony

Une vrai démonstration de l’approche à avoir pour vraiment optimiser son application. Plutôt que de se demander si echo sera plus rapide avec une virgule ou un point.

Il encourage de logguer en base, pour y avoir accès plus facilement et ajouter des notions de filtrage aisément et insiste sur les avantages du profiling, même s’il a oublié qu’un plugin Symfony était dispo pour ça .

On a pu noter les outils utilisés pour le benchmark et les metrics, Tsung et Graphite, que je ne connaissais pas. Toujours ça de bon à prendre aussi !

Une présentation très complète mais rien d’inédit que vous trouverez dans les slides.

Yahoooo

Comme d’habitude, Dustin, membre de la core team, et Yahoo man est venu présenter un peu le boulot de Yahoo autour de symfony. Pourquoi symfony, leurs contributions, leurs modifications.
Un petit tour des sites actuels développés sur le framework, avec un slide où on a pu apercevoir Shopgenie \o/ – la version anglaise de MonsieurPrix, développée par moi même ;) ca fait toujours plaisir!

Il a ensuite abordé le développement d’application web plus généralement et les bonnes questions à se poser concernant les choix à faire dans le design d’une architecture. Avec en guise de conclusion, une transition toute trouvée : “Symfony 2 is the right direction” !

On notera au passage un petit sondage de l’assistance sur les framework js, que jQuery a remporté avec une écrasante majorité.

Voir les slides

Symfony 2 preview

Est arrivée, la présentation que tout le monde attendait, Symfony 2 ! Il faudrait un billet dédié à lui même, et on va beaucoup en parler dans les prochaines semaines, donc je vais pas m’attarder longtemps.

On peut retenir, que Symfony 2 sera orienté configuration – tout est configurable – et couplage faible avec un passage sur PHP 5.3. Il ne sera plus question également de développer des choses annexes, comme le logger ou le système de cache, mais d’utiliser des librairies reconnues pour ça (dont celles du Zend Framework justement).

Il a bien insisté sur le fait, que Symfony 2 pourra faire exactement les mêmes choses que la version 1, mais plus simplement et surtout plus rapidement. Avec par exemple, le lazy load – on charge seulement ce dont le framework a besoin.

Avec une conclusion “Faster as hell! “.

Bon il n’aura pas échappé à l’effet démo, avec une tentative de commit de la preview release en direct, qui s’est soldée également par un échec. Le compte Wifi de la Cité Universitaire était expiré ;-) Mais vous pouvez désormais récupérer le code source de cette première version et faire joujou avec sur le site dédié à Symfony 2 !

Voir les slides

Il ne restait plus qu’à faire le chemin inverse, Direction Marseille. En espérant avoir l’occasion de revenir ;)

Vos envoyés spéciaux pour l’évènement: Vince et Tim

Crédit photo: http://www.flickr.com/photos/xavierbriand/4368850785/in/set-72157623335239339/

Et bien ça tombe bien car Vince et moi même avons la chance d’y être également !

Se rendre au Symfony Live

Bon ce fut tout un marathon pour moi, levé 5h30 (et ceux qui me connaissent savent que c’est déjà un exploit :D), tram puis métro pour attraper mon TGV Marseille-Paris de 6h30.
Arrivé à la gare de Lyon à 9h30, on repart pour une session métro, pour enchainer sur à nouveau un peu de tram avant d’arriver devant la Cité Internationale, endroit de Paris que je ne connaissais pas !

C’est déjà une belle surprise, l’endroit est fort sympathique, très joli, mais très graaand. Et j’ai pas trouvé les grandes affiches que j’attendais “Symfony C’est par là”. Bon finalement je débarque sur les coups de 10h30, badge, tour de cou et petit sac de goodies pour m’accueillir et me voilà dans l’arène.

Heureusement, il restait quelques croissants, parce que forcément j’avais fait l’impasse sur le petit déjeuner et je vais pas vous rappeler les tarifs prohibitifs de la SNCF. Juste de quoi me réveiller un peu et commencer à mettre en route mon cerveau qui jusque là ne voulait qu’une chose, se coucher.

la matinée

Internationalisation

On commence la journée par la présentation de Thomas Rabaix concernant l’internationalisation et Symfony.

Quelques rappels sur ce qu’est l’internationalisation, des astuces sympa comme comment traduire vos routes, mais aussi et surtout la présentation du plugin qu’il a réalisé pour Menu Gourmet : mgI18nPlugin. Il permet de traduire à la volée toutes les chaînes statiques de votre page en utilisant une petit interface qui se place au dessus du site, à essayer d’urgence !
Bref très bonne première présentation.

Vous pourrez trouver les slides de sa présentation sur son site.

Admin generator en détail

John Cleveley nous a fait une petite piqure de rappel des nouveautés de l’admin generator depuis la version 1.0. Il a aussi été l’auteur du slide le plus classe de la journée concernant l’administration “backend” : un éléphant se soulageant le derrière dans un seau … ;-)

Il a rappelé que l’admin generator c’était bien, mais pas forcément pour tout. Qu’il fallait réfléchir au besoin avant de l’utiliser, plutôt que de partir avec tête baissée et se rendre compte plus tard qu’on passe plus de temps à galérer avec par rapport à ce qu’on veut faire qu’autre chose (sa remarque est d’ailleurs valable pour tout développement : c’est généralement une bonne idée de réfléchir avant de se lancer ! ).

Si vous voulez créer votre propre thème, vous pouvez vous inspirer de sfAdminDashPlugin et de sfAdminThemejRollerPlugin.

Il a aussi re-précisé que sfContext::getInstance c’était le mal (même si lui l’utilisait dans ses slides) et a fini par parler de la facilité de modifier/étendre les filtres grâce au form framework. En ce qui concerne les form, il est préférable d’en créer un nouveau pour chaque form du backend, histoire de pas confondre les forms front et back.

Il a conseillé d’utiliser le moins possible le generator pour les label, help etc des forms, mais de tout laisser dans le form : beaucoup plus facile à maintenir.

Windows plaide coupable

Surement parce qu’ils sont sponsor, on a retrouvé une équipe de Microsoft qui a plaidé pendant 50 longues minutes que Microsoft c’était aussi (et presque surtout) de l’open source et que développer dessus, c’était bien. Apparemment pas assez pour donner envie de poser des questions à l’auditoire.

Bon, ok sur windows, tu peux développer sur Visual Studio 2010 Ultimate, what else?

Du coup un petit sondage a été lancé sur la répartition des OS pour les devs symfony

L’aprèm

Symfony Internals

Pas de nouveautés pour tous les développeurs qui ont pu travailler un peu en profondeur sur ce framework. Une belle revue de tout le fonctionnement interne de Symfony par Geoffrey Bachelet, et avec un accent so french ;)

Voir les slides

Doctrine migration

Un bon rappel sur l’enjeu des migrations et que maintenant (depuis sf 1.3) cela consiste en 3 opérations :

• Modifier son schema.yml pour inclure nos modifications
• Lancer la task de diff:
  symfony doctrine:generate-migrations-diff
• Regénérer ces classes model/form/filter et lancer la migration:
  symfony doctrine:build --all-classes --and-migrate

Alors pourquoi s’en priver?

Voir les slides

Doctrine 2

Est arrivé le tour de chauffe des gros sujets de la conférence. En l’occurrence Doctrine 2. Les grandes idées que Jonathan nous a montré:

• 100% réécrit, donc plus de compatibilité descendante
• ~ 3 fois plus rapide que Doctrine 1.2
• Principalement concentré sur la perf, et donc adieu la magie des findByMaColonne et consor. A l’image de Propel, les getteur et setteur seront générés dans la class model vu que les modèles justement n’hériteront plus d’une class de type Record, permettant ainsi d’alléger la charge mémoire
• Intégration d’une classe qui s’occupera, à l’image du monde java, de gérer les flush et clear. Ca ne sera plus l’objet en lui même qu’il faudra “save” mais demander à cette nouvelle classe de le faire.

Forcément, ca fait un peu peur, car au delà, d’une réécriture, ce sont des gros changements. Mais dans un souci de performance (aussi bien en terme de temps d’exécution que de charge mémoire), on prend le bon chemin. Même si la magie va disparaître…

Voir les slides

Offline admin generator

Sur cette partie, on a retrouvé Thomat Parizot, de chez clever-age (vous savez ceux qui ont annoncé un plugin de gestion de media au dernier symfony live, mais qu’on attend toujours :p).
On découvre un concept plutôt innovant dans le monde symfony, l’idée de permettre l’accès et le travail sur un backoffice sans connexion Internet semble une bonne idée. Il suffit de synchroniser, après coup, son travail.

Bon ok la démo n’a pas été parfaite – ahh l’effet démo – mais ya quand même un gros boulot derrière même si malheureusement c’est un concept très (trop?) dépendant de la technologie, vu qu’après Gears, il se base maintenant sur HTML5 et toutes ces nouvelles fonctionnalités. Donc très limité, mais à garder sous le coude.

Help the community

Skoop a redonner toutes les clés pour aider la communauté. Et que même les petites actions, comme les ouvertures de bug, sont très appréciées.

Voir les slides

Table ronde avec la core team

Pas mal de questions sur les sujets classiques, hello world application, et consor. Voici un petit recap des questions que j’ai comprises et trouvées intéressantes:

Q: Compatibilité descendante avec la fin du support de la 1.0

R: Gros effort sur la facilité de passer à une version supérieure

Q: Documentation du système de form un peu en retrait?

R: Ne pas hésiter à aider!

Q: Symfony enseigné à l’école? Support de cours disponibles?

R: PHP déjà peut enseigné de base. Pas plus d’info à ce sujet mais ne pas hésiter à les contacter sur ce sujet

Q: Développement ne va pas trop vite?

R: La 1.4 aura bien 3 ans de support, ce qui est en soi, très long. Et puis le web évolue vite, donc il faut suivre

Q: Performance? Quid?

R: Le problème vient rarement du framework… :D

Q: Difficulté à faire adopter Symfony par leur client

R: C’est ensemble et en fournissant des cas d’utilisation précis de Symfony, qu’on pourra faire évoluer les mentalités

Q: Sismo? Bientôt dans les bacs?

R: Fabien n’a plus le temps pour l’instant. Projet en standby et clairement pas prioritaire. Et de toute façon Sismo ne fera jamais tout ce que fait Hudson et consor. Il n’a pas écarté la possibilité de ne jamais le release…

Q: Quid de la construction d’un vrai CMS Symfony une bonne foi pour toute?

R: Déjà 3 CMS existant très solides, avec 3 approches différentes. Il faut en débattre.

Q: Pourquoi reprendre plein de projets, comme Swift?

R: Une volonté de ne pas réinventer la roue et de récupérer et adapter les meilleurs pratiques et idées en PHP

Q: Et Propel dans tout ça?

R: Gros boulot de François, mais peut-être un peu trop tard? Jamais dire jamais, mais pour l’instant après le gros switch vers Doctrine, difficile de faire machine arrière. Surtout que le futur de Propel avec sa 2.0 n’est pas du tout assuré pour l’instant

Et du coup, quelques annonces sont sorties:

• phpbb4 sera codé en Symfony 2, ce qui en ferait le premier gros projet open source php entièrement en Symfony si je ne m’abuse
• Symfony2 n’a plus de plugin mais des bundles…
• Symfony2 n’utilisera plus que le meilleur des autres framework, comme le logger et le cache de Zend, au lieu de le recoder de leur côté.

Voilà un petit compte rendu, les slides des différentes interventions sont disponible sur le blog de Symfony.

Vos envoyés spéciaux pour l’évènement: Vince et Tim

crédit photo: http://www.flickr.com/photos/iph4n70m/4338366087/