Cédric SADAI - Consulting en stratégie Internet

Posté par Cedric, le 21/12/2008 - Technologie

Jobeet est un tutorial en 24 parties, destiné à couvrir l'ensemble des fonctions offertes par le framework symfony dans le contexte de réalisation d'un projet réel. Alors que la série touche à sa fin, on peut faire quelques observations:

#1 L'ordre des cours

L'équipe symfony a choisi de partir du cahier des charges (sous formes de stories, respectant les principes de l'XP), pour ouvrir les hostilités par le design, juste après la conception du modèle de données, avant de s'attaquer en profondeur à la couche métier.

C'est précisément l'ordre par lequel nous avons également eu le moins de surprises. Juste après la conception de données, nous nous attardons même sur le conception visuelle de l'ensemble des parties où l'utilisateur peut entrer des données. Généralement, donc, le back office. En plus du design des formulaires (très utile pour repasser ensuite aux formulaires objets, faire les bons empilements de formulaires et développer les bons widgets), on peut également designer les différentes listes proposées à l'administrateur, ainsi que les interactions qu'il devrait être en mesure de faire à partir de là (et les implémenter basiquement, y compris l'éventuelle couche javascript).

Il s'agit en fait d'un bon moyen pour se rendre compte des éventuelles incohérences de conception, puisqu'en partant de toutes les possibilités d'entrées de données, il est facile d'adapter le modèle de données au mieux, l'affichage en front n'étant très souvent qu'une simple exploitation de données entrées par ailleurs (ou alors, si ce n'est pas le cas, il convient dinclure ces interactions utilisateurs en front dans ce prototypage graphique du début). Commencer par l'aspect visuel permet aussi de rapidement traduire vos scénarii d'utilisation en modules, actions, et routes correspondantes.

#2 L'importance des plugins

Nous avons beaucoup aimé le retour appuyé sur l'utilité des plugins. En effet, les plugins ne sont pas uniquement des packages publics prets à l'emploi. Ils sont aussi peut être le meilleur moyen de développer la véritable intelligence de votre projet. En effet, leur réutilisation est extrêmement simple, et se résume souvent à copier/coller un répertoire, qui lui reprend l'ensemble de votre travail.

Ainsi, dans les traitements de la couche modèle que nous faisons, nous travaillons par itérations succsessives:

1/ définition du comportement souhaité (exemple, un modèle Article doit etre taggé par un modèle Tag)

2/ qualification selon le critère "besoin ponctuel" ou "fonctionnalité réutilisable". Si la fonctionnalité doit être réutilisée, soit sur un autre modèle du même projet (ex: modèle Video), soit sur un autre projet, nous pensons "plugin".

3/ Comme nous travaillons désormais uniquement sur Doctrine, nous avons le bonheur d'utiliser très régulièrement les Templates, natifs à l'ORM. Pour chaque template que nous créons, nous créons un plugin correspondant.

4/ Si des interactions utilisateurs sont propres à cette fonctionnalité, nous les ajoutons au plugin. Par exemple dans notre cas, nous pouvons y intégrer une interface d'administration pour voir la liste des tags et en supprimer, ou encore un widget spécial qui étend une fonctionnalité jQuery qui va puiser dans notre liste de tags pour auto-alimenter un champs text avec suggestions AJAX (qui lui même pourrait étendre ce widget déja existant).

Ainsi, l'application pure de notre système se résume à définir le comportement dans le modèle de données (actAs: Taggable), puis de définir notre nouveau widget dans notre formulaire (sfForm::setWidget('field' => myWidgetFormInputWhatever)). En bref, une fois que le plugin est développé, deux minutes de travail réutilisables sur tous nos modèles.

#3 L'ouverture sur le monde

Le move stratégique le plus intéressant de cette série de tutoriaux est d'avoir inscrit clairement symfony non comme une solution s'opposant aux autres offres du marché, mais comme une solution complémentaire, et en particulier un produit complémentaire du framework Zend.

C'est également une pratique que nous apprécions. En effet, de si nombreuses librairies ayant été développées pour Zend, qu'il serait contraire au principe DRY de vouloir réinventer la roue. De plus, symfony permet d'intégrer facilement n'importe quelle librairie externe. Zend_Rest, Zend_Gdata, Zend_Amf, Zend_Search_Lucene, et bien d'autres encore sont des librairies magnifiques tant elles vous font gagner du temps de développement.

En bref, ces tutoriaux nous ont fait découvrir le symfony que nous pratiquons et que nous aimons: une plateforme complète et fiable qui s'intègre avec toute l'intelligence créée par ailleurs, et qu'on peut vraiment développer de manière modulaire et incrémentale en réutilisant systématiquement chaque entité développée.

C'est en programmant de cette manière (avec des tests systématiques et complets) que l'ont peut beaucoup gagner en productivité, à mesure que l'expérience s'accumule.