Symfony2 beta1 – Notes

Maintenant que Symfony 2 est disponible en beta 1, je n’ai pas pu résister, il fallait que je fasse quelques tests.
J’ai joué avec Doctrine2 ORM, les formulaires, les formats (_format json ou html), la gestions des erreurs (404, 500). J’ai aussi utilisé backbone.js (YESS!!! Me like!!!) et Aloha Editor, peut-être que j’En parlerai un jour…

La seule chose qui n’a pas fonctionnée (et il m’a fallu moins d’une minute pour trouver la solutions – merci Google!): la version courte du tag Twig « trans » n’est plus supportée.
Dans tous les cas, il faut garder un oeil sur la liste des updates qui brise la compatibilité: https://github.com/symfony/symfony/blob/master/UPDATE.md
Wow!

Notes intéressantes

Autoload et Bundle Registration

Plus de magie: il faut déclarer toutes les librairies que vous utiliser dans autoload.php. En espérant que la librairie que vous voulez utiliser utilise la convention PSR-0 ou PEAR (qui voudrait inclure une librairie non-PSR-0 anyway ;)).

En fait, j’aime ça: on sait ce qui est utilisé dans le projet.

AdminBundle

Ça fait 2 fois que j’essaie d’installer ce Bundle (remplace l’admin-generator de symfony1), mais encore une fois sans succès… En espérant que maintenant que Symfony 2 est en beta, les développeurs vont updater ce Bundle (oui, je sais, j’aurais pu essayer de le fixer, au moins un peu… Pas le temps!)

Doctrine 2

Toute en douceur, même si je n’ai pas fait des choses intensives (2 tables simples simples simples…). J’ai aimé le fait que la classe du modèle soit uniquement responsable de ce qu’elle doit être responsable (au revoir active record, bonjour Data Mapper).

Par contre, les behaviours de Doctrine 2 étaient vraiment pratique. Même si il y a quelques plugins qui existent (pas eu le temps de les tester, comme ça), il va falloir attendre les traits (php 5.4?) pour avoir quelque chose de facile à utiliser. Ca va nous forcer à monter des solides hiérarchies de classes probablement (une bonne chose), ou à utiliser les events…

Ah, aussi, l’article sur les fixtures Doctrine dans le cookbook fonctionne bien. Du php pur, pas de yaml… Ok avec ça, sauf pour les gens de QA… Donc ca va être su deéveloppeur de se monter quelque chose… ou le Bundle pour les fixtures va être améliorer (mais problème de naming convention: avec les setters et getters des modèles vs les attributs  qui devraient normalement être private ou au moins protected si vous avez du « coeur », quoique le Form Component demande de suivre des « naming convention » – lorsqu’on passe un objet à un formulaire…).

Ajout par rapport à Doctrine (2011-05-07):

Après quelques tests un peu plus poussés (mais pas trop…), je me suis demandé s’il y  avait un mécanisme similaire aux classes XxxxTable.class.php de Doctrine 1.2. Et oui!! Cela existe heureusement, et cela s’appelle un Repository. Merci à Richard McIntyre pour son article. Voir aussi la documentation Doctrine officielle correspondante (un peu caché et un peu court, non?).

error template

– les templates 404 et 500 supporte les templates Twig (symfony 1 offrait la possibilité d’avoir une page 500 mais elle n’était pas prise en charge par le framework (ce qui se comprend bien… ) et peuvent hériter d’un autre template. Mais attention: trop de logique et de code peut générer une autre erreur. Et là, vous n’obtiendrai qu’une page toute blanche…

– c’est le même template (error.html.twig pour la version html) qui est utilisé pour les 404 et 500 – c’est au développeur de mettre en place une logique « switch » sur le status_code s’il veut avoir différentes pages 404 et 500. Mais peut-être qu’il y a une autre manière de gérer la page 404 dans le routing, à la Sinatra par exemple? Histoire à suivre… Update (probablement disponible en beta2): C’est maintenant possible: Il suffit d’avoir un template errorXXX.html.twig par exemple, ou XXX est le status code http (404, 500, 403…). Si ce template n’existe pas, alors error.html.twig sera utilisé.

« app.yml is gone »

Je n’ai pas trouvé de recommendation dans le « book » pour conserver les settings et paramètres d’une application, par environnement. J’imagine que « import » dans config.yml et le Yaml component permettent de faire ça très facilement.

Dans le même ordre d’idée, je n’ai pas trouvé de détails sur config.yml dans le profiler…

Conclusion

Bon, en un mot, j’ai bien hâte de l’utiliser sur un vrai projet! Je vous en reparlerai à ce moment-là… Histoire à suivre donc…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *