Actualité Symfony, Doctrine et Propel

journal-cafe-netbook Comme souvent après la rentrée, on assiste au débarquement des nouvelles versions en tout genre, comme Apple avec Snow Leopard ou Karmic Koala chez Canonical (bon ok eux c’est tous les mois d’octobre :p).

Et forcément, chez les développeurs Symfony, ca frétille d’impatience car chaque jour nous rapproche de la sortie de la version 1.3 de notre framework PHP préféré, dernière release majeure avant le passage en 2.0 (oué pour le coup, ils sont pas encore à la mode).

Je me suis dis que ca valait le coup de faire un petit tour d’horizon des nouveautés attendues (au moins par moi) que se soit Symfony, Doctrine et même Propel:

Propel

On commence avec le feuilleton de l’été. Propel, mourra, mourra pas?

L’info a très vite circulé, et Propel a été enterré très vite après l’annonce de son créateur Hans Lellelid d’arrêter là les frais.

Mais dans son message, il y avait bien un appel au passage de relai, appel auquel François Zaninotto (himself, ex de la core team Symfony) et Sven Teitje ont répondu. Le premier prenant en charge l’évolution de la branche 1.x et le second le développement de la nouvelle branche 2.x.

D’ailleurs ils n’ont pas trainé car on parle déjà de Propel 1.4! On suivra bien sûr ça de très près.

Doctrine

Avec la mode 2.0, Mister Wage prépare lui aussi une version 2.0 de son ORM Doctrine. Peu d’infos encore si ce n’est qu’il sera plus beau, plus fort et surtout plus rapide! Grâce à PHP 5.3 en particulier.
Mais on pourra également retrouver des messages d’erreurs localisés! Et ça c’est la classe.

Mais ceci reste du futur pas proche. Et on va s’intéresser plutôt à la version 1.2, celle qui accompagnera la version 1.3 de Symfony (oui j’avoue, ils auraient pu se mettre d’accord sur les numéros de version, ça aurait été plus simple).

Et la nouveauté majeure pour moi, c’est la possibilité d’étendre les classe de Doctrine facilement et en particulier Doctrine_Query et Doctrine_Collection. On pourra alors généraliser certains comportements et ajouter de nouvelles fonctionnalités comme des tri personnalisés dans les collections ou adapter l’idée de NiKo pour les query.

On notera également, l’ajout d’un système d’extension directement via doctrine qui sont en fait des behaviors. Vous retrouverez la liste sur le site lui même. J’ai d’ailleurs de mon côté, une petite idée d’extension, mais on en reparlera le moment voulu ;)

Symfony

Gros programme pour cette dernière release (comme annoncée, la 1.4 ne sera qu’une 1.3 débarrassé des méthodes/classes dépréciées). Beaucoup de choses, mais voici un résumé de celles que j’attends vraiment:

  • La vrai nouveauté, un Mailer de série! Basé sur Swift, très bonne librairie, cela fera toujours un plugin de moins à utiliser
  • Le système de formulaire pluggué sur le système d’évènement avec 4 nouveaux évènements qui va permettre enfin de généraliser des comportements pour certains formulaires très facilement.
  • Pouvoir ne pas générer les formulaires ou filtres d’un modèle lors de sa définition dans le schema.yml (seulement doctrine). Nan parce que, c’est vrai que des fois, on en a vraiment pas besoin.
  • Petit détail enfin corrigé, les pager intègrent enfin les interfaces Countable et Iterator.
  • Autre détail, à la génération automatique d’un label d’un champ de formulaire, les _id seront supprimés! Ca permettra d’avoir quelque chose de présentable plus facilement, pcq les _id nous on les voit pas, mais les clients, ca leur saute toujours aux yeux ;)
  • Petite révolution dans les définitions de formulaire. Actuellement, il faut retirer du formulaire les champs qu’on ne souhaite pas voir s’afficher. Mais le coup classique du « je rajoute un champ et il apparait automatiquement alors que je voulais pas » ça agace. Dans la 1.3, ca sera donc l’inverse, il faudra spécifier les champs qu’on voudra afficher grâce à la nouvelle méthode useFields
  • Niveau CLI aussi beaucoup de nouveautés, dont une assez formidable, la possibilité de rejouer seulement les tests qui auront échoué! Il suffira de rajouter l’option –only-failed.
  • Pour Doctrine aussi, beaucoup de rajouts bien pratiques, comme la possibilité de regénérer/supprimer les fichiers liés à un model donné. Et même de resynchroniser tous les modèles avec le schema.yml (entendre par là qu’il supprimera ceux qui n’existe plus). Des petits gains de temps qui ne sont pas de refus, surtout dans les débuts d’un nouveau projet.
  • Et bien sûr, la plus attendue pour la fin. Fabien en avait déjà parlé sur le blog, la possibilité de créer un installer pour la génération de nouveau projet qui fera automatiquement toutes les tâches de personnalisation que vous faisiez avant à la main ou en maintenant votre skeleton de projet.

En tout cas, ça fait envie, et ca va dans le bon sens selon moi. Pour tous les détails:

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

Tags: , , , ,

A propos de l'auteur

Développeur web spécialisé Symfony, il est avant tout passionné de web tout simplement. Il aime les défis et farfouiller dans le code de Symfony ou Doctrine. Fondateur du blog, il exerce chez Autrement.

Vous avez aimé ce billet? Faites le savoir!

  • Delicious
  • Twitter
  • Technorati Favorites
  • FriendFeed
  • Google Bookmarks
  • Share

4 Réponses

  1. MrMoins 21 septembre 2009 à 14 h 12 min #

    Je n’ai suivi que d’un oeil les annonces concernant les nouveautés a venir, merci pour cette remise a niveau, et je suis d’accord avec toi, ca va dans le bon sens, va falloir penser a faire des migrations moi je dis…

  2. Tim 21 septembre 2009 à 14 h 40 min #

    A vot’ service ;)

    Et si en plus on est d’accord, tout va bien :D

  3. Vince 29 septembre 2009 à 11 h 03 min #

    T’as oublié les interfaces fluides pour les widgets mon petit Tim !
    Pas mal mal d’entre vous ont déjà du faire des trucs du genre dans leurs forms :
    $this->widgetSchema['text']->setOption(‘…’);
    $this->widgetSchema['text']->setLabel(‘…’);
    $this->widgetSchema['text']->setAttribute(‘…’);

    Avec les interfaces fluides d’implémentées on va pouvoir faire de jolis :
    $this->widgetSchema['text']->setOption(‘…’)->setLabel(‘…’)->setAttribute(‘…’);

    C’est beau le progrès !

  4. Tim 29 septembre 2009 à 11 h 21 min #

    Effectivement!

    Merci mon petit Vince :D


Laisser un message