Tapestry est un framework MVC 2 (souvent cité comme l’une des implémentations les plus limpides) proposant un modèle de programmation orienté composant et ce bien avant JSF. Ce projet a été intégré par la fondation Apache, ce qui est un gage de pérennité.

Les principaux défauts de Tapestry sont la difficulté de prise en main, et la difficulté de trouver de la documentation ciblée (pour des problématiques spécifiques). En effet, il est souvent nécessaire de connaître le fonctionnement interne du framework pour l’utiliser proprement. Ce défaut, couplé au modèle de programmation novateur à l’époque (donc peu de ressources disponibles sur le marché) va nuire au développement de Tapestry.

Depuis mars 2007 Tapestry 5 est disponible en pre-version, la première version stable étant planifiée pour cet automne. Il s’agit d’un débranchement, donc la compatibilité ascendante n’est plus assurée. Tapestry 5 offre les évolutions suivantes :

• Les composants n’héritent plus de classes de base, il s’agit de simple POJOs
• Simplification du modèle de développement, basé sur des conventions plutôt que sur de la configuration.
• Utilisation des annotations Java en lieu et place des fichiers de configuration.
• Chargement à chaud automatique des ressources modifiées (aussi bien durant le développement qu’en production).
• Optimisation des performances.
• Logging implémenté avec SL4J qui contrairement à l’api JCL n’a pas de problèmes de classloader et de fuite mémoire.
• Ajout d’un composant d’upload basé sur les commons-fileupload.
• Simplification du module tapestry-spring.
• Simplification du module tapestry-ioc (suppression des concepts de namespace, id...) avec l’intégration des bonnes idées de google guice .
• Module Maven pour la génération de la documentation.
• Fonctionnalités Ajax dont l’usage a été simplifié par rapport à la version 4.1.
• Module d’intégration avec hibernate.
• Nouveaux composants pour les formulaires :
  • BeanEditForm (génération d’un formulaire à partir des propriétés du bean)
  • Grid (on sait à quel point il est difficile d’en implémenter une).

Conclusion

Lorsqu’une version stable sera livrée et que la documentation aura atteint un niveau de maturité convenable, j’opterai sans aucun doute pour la version 5. A l’heure actuelle je conseille l’utilisation de la version 4.1 :

• intégration Ajax avec DOJO (api JSON, annotation @EventListener, validation côté client basée sur DOJO...).
• l’utilisation des « templates » permet de dissocier clairement les rôles d’intégrateur HTML et de développeur.
• Composants réutilisables et évolutifs.
• debug de la couche présentation au « runtime ».
• support des portlets (JSR 168).
• bonne productivité. La prise en charge par le framework de problématiques récurrentes dans le développement d’applications Web (gestion des urls, de l’internationalisation, gestion des exceptions...) permet aux développeurs de se focaliser sur la logique métier.
• ...