Stripes : un autre framework MVC.

Stripes est un framework MVC orienté action, développé par Tim Fennel, et qui existe depuis 2005. Sa volonté est d'être une alternative à Struts 1.x (qui reste à ce jour, rappelons-le, le framework MVC le plus utilisé) et nous dirons de ce fait qu’il se situe dans le même « créneau ».

Stripes a beaucoup moins de visibilité et une communauté plus réduite que d'autres frameworks comme Struts 2 ou Spring MVC, mais il n'est pas sans atouts. Cet article en fera une présentation rapide.

Objectif zéro XML.

La première (bonne) surprise du framework est qu'il va à contre-courant de l'utilisation de fichiers de configuration. Ceux-ci, incontournables dès les débuts de la norme J2EE, ont leurs avantages, mais peuvent également s'avérer contraignants (refactorings, conflits de version, etc.).

La configuration de Stripes est minimale. Démarrer un projet nécessite de déclarer dans le web.xml un servlet et un filtre, et un seul paramètre d'initialisation obligatoire, "ActionResolver.Packages" définissant le ou les packages à partir desquels les classes ActionBean seront "découvertes". Conséquence : au sein de ces packages ces classes peuvent être déplacées et renommées à volonté sans autre impact.

Un second paramètre d'initialisation, optionnel mais presque indispensable, est "Extension.packages" (j'en reparle plus loin). C'est dans ces packages que Stripes recherchera et chargera les classes d'extension de son comportement, classes définies par les développeurs.

Le templating est un autre point où Stripes se passe d'un fichier de configuration (tel que tiles-defs.xml pour Struts) : à la place 3 tags simples et efficaces permettent de mettre en oeuvre un tel mécanisme.

Keep it simple.

Comme on le voit, Stripes insiste avant tout sur la légèreté. Le jar n'est pas énorme, et les dépendances réduites (Commons Logging). De manière générale, Stripes ne "réinvente pas la roue", ne cherche pas à tout gérer, mais au contraire facilite l'intégration. Pas de tag "table" par exemple, des librairies tiers existent. Autre exemple : la locale étant déterminée par un filtre, les tags stripes et fmt (jstl) peuvent être utilisés conjointement.

L'accent est également mis sur la rapidité d'apprentissage et de mise en oeuvre. Stripes utilise une logique "convention over configuration" qui permet de démarrer vite ; il y a un comportement par défaut, mais tout est redéfinissable et extensible, à travers nouveaux objets et héritages, que le paramètre "Extension.packages" (vous l'avez deviné) sert justement à débusquer.

Disons également que Stripes rentre dans la famille des frameworks qui ne cachent pas le protocole HTTP, mais l'acceptent et en tirent parti. Citons à ce propos les "patterns" conseillés : passer par une pré-action ; rediriger plutôt que forwarder après un effet de bord (Stripes fournit un "Flash Scope" permettant de garder des objets sous la main pour la requête courante ainsi que la suivante).

Derniers exemples de "l'esprit" du framework : les messages de plantage sont ciblés, font plusieurs lignes d'explication, et proposent des voies de résolution ; les tags Stripes "HTML" collent au plus près de leurs équivalents (y compris l'attribut class), permettant de passer facilement de l'un à l'autre.

Un peu d'Action.

Regardons le cœur du framework. A la base, rien de révolutionnaire. Un ActionBean n'impose pas d'héritage (la seule contrainte est d'implémenter une interface de 2 accesseurs) et le formulaire est représenté par des propriétés (on choisit souvent un javabean comme unique propriété). Une propriété (indexée ou non) représente un champ du formulaire, et une méthode représente une interaction, du moment qu'elle est publique et qu'elle retourne un objet Resolution. (Les Resolution "forward", "redirect", "stream", "javascript" et "http error" sont disponibles par défaut.) On n’est pas très loin de Struts 2.

Plus intéressante est la notion d'URL binding : la classe de l'ActionBean et l'url pour l'atteindre sont liées par convention. Exemple du binding par défaut : com.foo.bar.action.module.TestActionBean a pour url /module/test.action. Conséquence appréciable : dans un tag "link" ou "form" on peut spécifier l'action cible via son url, mais aussi via le nom qualifié de l'ActionBean ; ainsi, dans notre IDE, l'action est à un clic de souris de la jsp... Le binding peut bien sûr être modifié, globalement ou localement, et permettre par exemple d'utiliser une url /calendar/month/view/12 à la place de /calendar/month.action?view=&nbmonth=12. De plus, la variable "actionBean" étant disponible dans les jsp, un lien générique peut aussi s'écrire ainsi  : <s:link beanClass="${actionBean.class}"/>

Les annotations permettent aussi d'implémenter la validation côté serveur, ainsi que les "TypeConverter". Ceux-ci permettent une traduction des valeurs des champs de formulaire vers des données typées. L'extension Stripersist donne même la possibilité de baser ses converters sur JPA afin de charger directement les objets depuis une base de données. Les TypeConverter fournis par défaut sont assez souples (la plupart des dates seront interprétées sans effort de notre part). L'interface Formatter permet d'effectuer l'opération inverse.

En résumé, et surtout grâce aux annotations, c'est l'ActionBean qui l'endroit où s'effectue la configuration, à la place d'un fichier externe.

Pour aller plus loin.

Je pourrais évoquer les objets "Interceptor", qui permettent de s'intercaler dans le flot du cycle requête-réponse (8 étapes définies par Stripes), via une méthode annotée dans l'ActionBean (intercepteur local) ou via une classe d'extension (intercepteur global). Ou encore du support d'Ajax, tout à fait honorable même s'il faut mettre la main à la pâte pour intégrer son framework js préféré, et si je regrette l'absence d'une JSONResolution.

Mais bref. Je vous laisse le soin de regarder plus avant si après cet aperçu vous jugez que les choix d'architecture de Stripes font de lui une alternative intéressante dans le cadre de certains projets.

La documentation se trouve à http://www.stripesframework.org ; elle est claire et agréable, quoique pas très organisée.

Le livre de référence est celui du français Frédéric Daoud : "Stripes... and Java web development is fun again". Il est également très clair et fournit de nombreux exemples.

2 commentaires

  1. Pour l’utiliser tous les jours depuis bientot deux ans, je trouve ce framework très agréable à utiliser.
    Taglib et binding efficace, aucun fichier de configuration, facilités pour le refactoring, intercepteurs a chaque cycle…

    Il nécessite tout de même, comme tout framework de binding, un minimum de discipline: pas toujours évident de gérer les erreurs de validation, comprendre quand utiliser la strategie de binding dans l’entité, et celle de binding dans pojo + merge dans l’entité.

    Le code du framework est agréable a lire et facile à comprendre. Ce framework ne fait pas de « choses magiques », c’est beaucoup plus simple que Spring ou Hibernate tout en restant efficace.

    Aujourd’hui c’est surtout Ben Gunter (sur #stripes @ freenode) qui maintient le framework. Les bugs sont corrigés assez rapidement, de même pour les RFE. Il y a des releases régulièrement, le projet est stable.

    Qui l’utilise? C’est le framework choisi chez FullSix/Ekino pour la majorité de ses clients. On retrouve donc du Stripes sur, entre autres, Renault et SFR.

Laisser un commentaire

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

Captcha *