Quelques semaines après l’événement le plus attendu de l’année dans la communauté des développeurs symfony, à savoir le symfony live, je vous livre ici les points clés de cette édition 2010.
Les deux jours de conférences ont été marqués par les présentations officielles de Doctrine 2 et Symfony 2, je reviendrais sur ces deux points ultérieurement.
Sur la vingtaine de conférences proposées, je vais parler de celles qui m’ont le plus intéressées et surtout des astuces / conseils que j’ai pu glaner à l’écoute de cette brochette d’excellents intervenants.
_ Les résumés sont dans l’ordre chronologique.
I18n dans symfony par Thomas Rabaix
Première conférence de la journée, l’internationalisation en symfony par Thomas Rabaix ! Thomas est l’auteur de nombreux plugins fort intéressants, dont l’excellent mgI18nPlugin, qui permet d’éditer la traduction d’un site directement depuis la web debug toolbar de symfony. Il est donc très bien placé pour nous parler des fonctions d’I18n et l10n proposées par le framework.
Au cours de la présentation, Thomas a donc fait le tour des différentes solutions pour internationaliser les vues, les formulaires et le routing de symfony. Et pour ce dernier, on se rend compte que la meilleure solution est finalement de développer soi-même sa propre classe de routing (la traduction des URLs n’étant pas aisée avec les composants de base).
Outre les divers rappels toujours utiles (le paramètre :sf_culture dans le routing qui influe sur la culture de l’utilisateur, le troisième paramètre de __() à ne pas négliger…), c’est surtout la traduction des formulaires qui a retenu toute mon attention.
On y a retrouvé un très bon résumé pratique de la documentation, et un avertissement bien utile : en symfony 1.3/1.4, les « choices » passés à un widget de type Select, par exemple, sont automatiquement envoyés à l’I18n.
Enfin, afin d’éviter de faire un appel à sfContext::getInstance() pour obtenir la culture de l’utilisateur dans un formulaire, une solution élégante est de passer la culture en option du sfForm ! (voir diapo 23). Utiliser sfContext est en effet une mauvaise pratique car cela empêche de tester vos formulaires.
D’un point de vue performance, on apprend aussi qu’il n’y a aucune différence entre SQL, XLIFF… pour le stockage des traductions, car dans tous les cas elles sont mises en cache par symfony.
_ Ce fut une très bonne entrée en matière pour ce symfony live 2010 !
Travailler avec le générateur d’admin par John Cleveley
Le générateur d’admin est un des outils les plus importants dans symfony, mais sa richesse a des limites. John nous a très bien remis les pieds sur terre : il ne faut pas utiliser le générateur pour tout et n’importe quoi ! Si un module nécessite un workflow qui sort de l’ordinaire, il ne vaut mieux pas s’encombrer de l’admin generator.
Cette conférence était pleine de bons conseils, par exemple, si vous avez besoin de rendre un generator.yml dynamique, sachez qu’il est possible de modifier cette configuration directement dans le fichier de configuration PHP de votre module, et donc de faire appel à tout le PHP que vous voulez.
Côté performance, il est aussi conseillé d’optimiser les requêtes de l’action « list » (les JOIN ne se font pas automatiquement, mais sont très simples à ajouter manuellement). A éviter aussi, le fait de mettre les labels du formulaire dans le generator.yml (car si vous voulez utiliser ce même formulaire ailleurs par la suite, vous n’aurez plus vos labels).
John nous as aussi parlé d’un widget particulier, qui permet de simplement afficher un champ (sans possibilité d’édition) : sfWidgetFormPlain (pas encore disponible mais sera peut être dans sfFormExtra) et nous a finalement appris comment créer un thème pour le générateur d’admin, et c’est bien plus simple qu’il n’y paraît.
Les migrations Doctrine par Dennis Benkert
Je ne reviens pas sur les explications techniques concernant les migrations Doctrine, si le sujet vous intéresse, je trouve les slides suffisamment riches et détaillés. De plus, la documentation n’est pas en reste sur cette feature. J’aimerai simplement revenir sur la discussion qui a suivi la présentation de Dennis.
Dans le cadre d’une migration de données, il est parfois nécessaire de manipuler le modèle de données dans la classe de migration. Seulement un des problèmes soulevé par l’assemblée est que DoctrineTable n’est pas accessible, et n’est de toutes façons pas mis à jour par les opérations de migration. Vous auriez donc encore votre ancien modèle chargé par symfony.
_ Une solution évoquée est de séparer la migration du modèle et celle des données dans deux classes différentes, et de les lancer l’une après l’autre (et non pas en même temps, car le processus de migration est englobé dans une transaction et DoctrineTable n’est pas rechargé).
Dans un autre registre, on se demande aussi pourquoi la tâche de migration Doctrine n’effectue pas un lock du projet durant son exécution… (vous pouvez le faire vous même avec la tâche project:disable).
Doctrine 2 : Not the Same Old PHP ORM par Jonathan « God » Wage
Jonathan Wage nous a présenté le futur Doctrine, un ORM entièrement repensé et réécrit pour PHP 5.3.
_ Toute la philosophie actuelle est à oublier. Fini la magie, les « wtf », l’hydratation gaspilleuse de ressource (et lente !), les Doctrine_Record impossible à var_dumper, les save()…
Je vous invite vraiment à consulter les slides de la présentation, car je ne vais pas tout répéter ici. Mais en quelques mots, les Records actuels deviennent des entities : des classes PHP toutes bêtes avec une série de propriétés (les champs de votre table) et c’est tout. Pour les gérer (faire des save() par exemple), il faut faire appel à l’EntityManager.
Le DQL a été entièrement réécrit, aussi et on peut maintenant, en plus du traditionnel QueryBuilder, écrire nos requêtes en SQL :Select u from MyProjectModelUser u. A savoir que le parser de DQL n’est pas limité, et on pourra très simplement ajouter nos propres mots clés au langage !
Les performances devraient exploser Doctrine 1 et la version finale est attendue d’ici 6 mois (ou plus…). A savoir qu’il est déjà disponible sous forme de Bundle (et pour savoir ce qu’est un bundle, il faudra vous intéresser à Symfony 2 !).
Un admin générateur offline avec HTML 5 et Gears par Thomas Parisot
Thomas nous a présenté un prototype très intéressant d’admin générateur exploitant les nouvelles possibilités offertes par HTML 5, à savoir le stockage de donnée côté client.
Grâce à un simple plugin, et avec un navigateur compatible, il devient possible d’éditer les contenus d’un site sans la moindre connexion internet. On en reparlera certainement sur le site de Clever Age (il s’agit en effet d’un développement interne).
Optimiser le code PHP par Xavier de Cock
Nous sommes le deuxième jour, il est tôt, et Xavier de Cock va littéralement nous scotcher avec sa présentation !
Le monsieur est en effet un génie (ou un obsédé, c’est selon) de l’optimisation, et ça va très loin. On a ainsi pu constater par nous-mêmes qu’entre ces deux codes :
echo "Foo", " ", "Bar";
_ echo "Foo" . " " . "Bar";
C’est le second qui sera le plus lent, car il effectue des traitements sur les données. Et ce grâce à la lecture de l’OPcode généré par le ZendEngine. Alors oui, c’est négligeable, mais la lecture de l’OPcode révèle bien d’autres surprises.
Ainsi, j’ai appris que si j’assignais la même valeur à deux variables, Zend s’en rend compte et ne stockait ma donnée qu’une seule fois en mémoire ! Il est fort ce Zend 🙂
Plus sérieusement, il est fortement conseillé ici de passer à PHP 5.3, pour bénéficier du nouveau garbage collector et ainsi éviter les memory leaks dûs aux références redondantes.
Et si on mettait à jour http://gophp5.org/ ?
Git 101 par Scott Chacon
Comme vous le savez peut-être, la core team à décidé de changer de gestionnaire de version et Symfony 2 utilise donc Git en lieu et place de notre bien aimé subversion.
Cela explique la présence et l’intervention de Scott Chacon (GitHub et auteur du livre de référence sur Git, ProGit), qui en plus d’être un orateur talentueux nous a exposé en détail la révolution Git.
J’en retiens qu’en tant que gestionnaire de versions, c’est certainement ce qui se fait de mieux à l’heure actuelle. Tout parait plus logique, plus simple et surtout plus rapide : faire tous les « commits » en local, merger, forker et merger pour reforker et remerger… et ce même sans serveur (on peut facilement avoir un dépôt Git en local en plus).
_ On peux aussi switcher son workspace d’une branche à une autre avec une simple commande (et là tous le monde dit waah).
Bien que l’outil soit essentiellement destiné à la ligne de commande, on voit fleurir des plugins pour tous les IDE en place, Egit pour Eclipse et NBgit pour Netbeans notamment.
A suivre et à essayer !
Les events symfony par Dennis Benkert
Symfony dispose d’un Event Dispatcher interne auquel on peut enregistrer des listener et notifier des événements (jusque là tous le monde suit ?), et la présentation de Dennis était sur ce point très intéressante.
Beaucoup de bonnes pratiques, d’explications et de détails concernant l’utilisation de l’Event Dispatcher de symfony sont distillés tout au long de ces slides (que je vous invite à lire), j’en retiens surtout les points négatifs :
– Il n’est pas possible de spécifier l’ordre des actions branchées sur un événement (si par exemple on connecte deux méthodes à l’événement registration.complete, on ne peut pas prévoir l’ordre dans lequel les méthodes vont être exécutées)
– Les événements, c’est compliqué à débugger (pas facile à suivre, il est alors recommandé de ne pas être avare en log)
– Les évènements, c’est lent (à chaque notify, toute la chaine d’Events et parcourue)
Bien sûr tout n’est pas noir, à vous d’utiliser correctement et uniquement quand c’est nécessaire les Events qui sont une feature bien utile dans certains cas.
Symfony dans le cloud par Kris Wallsmith
Une des présentation les plus fun de la journée 🙂
Kris nous a exposé quelques détails techniques concernant l’utilisation et le déploiement d’un projet symfony sur un « Cloud » (comprendre nuage de serveurs). En effet il arrive souvent que pour un site à fort trafic, une seule machine ne soit pas suffisante. On en utilise alors plusieurs, avec parfois plusieurs serveurs de base de données, et plusieurs serveurs Web et donc plusieurs instances de PHP.
_ Cela impose quelques contraintes techniques (comme l’impossibilité d’utiliser les sessions native de PHP) heureusement facilement contournables grâce à symfony.
Dans le cas de Kris, on a 3 bases de données : 1 en écriture et 2 en lecture seule (qui sont mises à jour régulièrement),
_ pour dire à symfony d’effectuer ces INSERT / UPDATE dans la première et de faire ces SELECT dans les autres, aléatoirement, il suffit d’étendre légérement Doctrine, et c’est exactement ce que fais le plugin sfDoctrineMasterSlavePlugin, releasé pour l’occasion.
_ Plus simple, c’est pas possible !
Concernant la gestion des sessions, il suffit de modifier la classe utilisée dans la factories.yml (sfSessionStorage par défaut), pour par exemple stocker les sessions en base de donnée.
Et concernant les uploads de fichiers, Kris recommande d’utiliser un service à la Amazon S3, déporter la gestion des uploads sur une unique ressource est en effet la meilleure solution et Amazon est un prestataire de qualité.
Une présentation fort intéressante avec un cas pratique décortiqué comme on les aime, la lecture des slides est ici aussi recommandée 🙂
Symfony 2 par Fabien Potencier
Dernière conférence et pas des moindres : Symfony 2 enfin révélé !
Dans cette présentation Fabien fait le tour de toutes les features et de la nouvelle philosophie du framework : autant vous le dire tout de suite, tout à changé.
Le passage à PHP 5.3 et le nouveau leitmotiv « less magic » implique que la rétro-compatibilité avec la version 1 du framework est entièrement cassée. Il y aura « peut être » des outils de migration comme à l’accoutumée mais je doute qu’il s’agira d’une tâche aisée tant les méthodes de développement diffèrent.
Tout est à présent prévu pour être flexible et configurable,
_ d’ailleurs il est maintenant possible d’utiliser XML pour les fichiers de configurations (et ainsi bénéficier de l’auto-complétion fournie par des IDE comme Netbeans, les XML possédant les schémas adéquats).
Il n’y a plus de Request, et on récupère nos paramètres directement dans la méthode de notre action :
public function maFonction($toto, $foo, $bar)
C’est le Routing qui se charge de tout.
Les Helpers sont maintenant de vrais objets et côté vue, c’est pareil : on est dans un contexte objet et $this est disponible.
_ Les variables obscures $sf_user et $sf_content disparaissent, le contenu est maintenant injecté dans le layout via un slot.
_ D’ailleurs les notions de include_partial et components sont remplacées par l’utilisation de simples slots.
De plus, comme pour tous les composants du framework, les helpers ne sont chargés que lorsqu’on en a besoin ! Il en va de même pour le User, le Request…) et ça se ressent sur les performances.
Les plugins sont maintenant nommés Bundles, il s’agit plus ou moins de la même chose à la différence près que dans Symfony 2, tout est Bundle (un peu à la Drupal (mais en mieux)).
Côté développement nous ne sommes pas en reste : l’environnement de dev à été revu et est maintenant aussi rapide qu’un environnement de prod ! La nouvelle page d’exceptions est plus complète (avec un dump de la sortie « avant exception ») et la WebDebug toolbar, maintenant placée en bas de page, est mieux pensée.
_ Les logs sont d’ailleurs moins nombreux mais plus intéressants.
La core team à décidé pour cette version de ne pas réinventer la roue, et d’utiliser des composants extérieurs lorsque cela se justifiait. Ainsi c’est le loggeur de Zend Framework, et les tests unitaires utilisent PHP Unit. Les sfComponents sont quand à eux toujours d’actualité (L’injecteur de dépendances notamment).
Toutes ces informations et un tutoriel de mise en pratique sont disponibles sur le site [http://symfony-reloaded.org/->http://symfony-reloaded.org/], les sources sont consultables sur GitHub bien entendu.
Petits détails à retenir :
– Symfony 2 s’écrit avec un S majuscule
– Sismo (le serveur d’intégration continue en php) ne sera certainement jamais releasé
– PhpBB 4 utilise Symfony 2
– sfForm, le grand absent de la présentation, n’est pas encore prêt mais va lui aussi être réécrit
Un grand merci aux organisateurs, et rendez-vous l’année prochaine 😉
