Tapestry | Blog Xebia France

Mettre au grenier la configuration XML et l’API J2EE, voilà le pari que tentent de relever les frameworks orientés composants. Pour atteindre ce but louable : simplifier la vie stressée du développeur et par là même sauver quelques-uns de ses cheveux, le XML est remplacé par du code Java et l’API J2EE est cachée dans les entrailles du framework. Les pages deviennent des objets Java liés à des templates, auxquels sont ajoutés des composants réutilisables (si, si). Les composants sont ni plus ni moins que d’autres objets Java liés à des templates. Les requêtes, quant à elles, deviennent des événements traités par les pages et les composants.

Voilà pour le principe de cette approche qui semble avoir de beaux jours devant elle. Emergence naturelle ou stratégie voulue, la fondation Apache, jamais avare de solutions, nous propose deux frameworks composants : Tapestry 5 et Wicket. Alors comment choisir ? Le mieux est encore de se faire sa propre idée en les testant tous les deux. Nous sommes bien d’accord, rien ne remplacera jamais l’efficacité du prototypage. Cela n’empêche pourtant pas de faire une pré-sélection basée sur quelques points de comparaisons stratégiques. Voici donc un article pour vous aider à faire le meilleur choix ; à savoir le choix qui répondra le mieux aux besoins et à l’environnement de votre projet.
Bien qu’adoptant tous deux la programmation web orientée composant, les deux projets sont imprégnés d’une philosophie et d’un objectif différents. Les buts principaux de Wicket sont :

Pages et composant statefull
Programmation à la Swing
Séparation stricte entre code et template

Pour Tapestry 5, les objectifs sont différents :

Optimiser l’utilisation CPU et mémoire
Simplifier la création de composants

Attention ! Ce sont là les objectifs sur lesquels les deux projets sont focalisés. Ce qui ne signifie pas qu’ils s’y intéressent exclusivement. Wicket supporte bien les composants sans état, ce n’est juste pas son but principal. De même que Tapestry supporte le développement web entièrement en objet Java.

Ils affichent, aussi, des buts communs, comme d’être orientés Pojo et d’éliminer la configuration XML avec le pattern Convention Over Configuration.

Lire la suite de cet article »

Revue de Presse Xebia

Article publié par Xebia France le 11 mai 2009.

Catégorie(s) : Revue de presse

Aucun commentaire »

Mots-clefs :@Inject, annotation, Datagrid, ESB, Fuji, Google, Guice, J2EE, Java / JEE, JavaFX, JSon, JSR-299, OpenESB, Paris JUG, RIA, SOA, Spring, SpringSource, Tapestry, Wicket

Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

SOA

Fuji, le futur d’OpenESB

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

Soirée Datagrid au Paris Jug

Lire la suite de cet article »

Commencer l’injection de dépendances avec Tapestry IoC

Article publié par Séven Le Mesle le 24 avril 2009.

Catégorie(s) : Java / JEE

Un commentaire »

Mots-clefs :annotation, dépendances, Guice, IoC, Java / JEE, Spring, Tapestry

Quand on parle d’injection de dépendances, on pense tout de suite à Spring qui se tient sous les feux de la rampe. On peut aussi penser au petit dernier Guice abordé dans l’article Google Guice 2 : Les bases de l’injection de dépendances. Mais il ne faudrait pas oublier Tapestry 5 qui, lui aussi, fournit sa solution pour l’injection de dépendances. Tapestry IoC, à ne pas confondre avec le framework de développement Web Tapestry 5, est très fortement inspiré de Guice. Son but affiché est de tirer le meilleur de Guice tout en apportant l’héritage de son grand frère défunt Hivemind. On garde donc l’objectif zéro XML en le remplacant par du code Java. Parmi les avantages de cette technique, on citera :

Le démarrage d’une application est plus rapide avec une configuration IOC en annotations Java qu’avec une configuration XML à parser
On peut tester unitairement les modules d’injection puisqu’il s’agit de classe Java simple
Finie la configuration laborieuse en XML

J’ai même envie de rajouter que l’apprentissage d’une API Java est bien plus rapide que celui d’une syntaxe XML. Tout comme Guice, Tapestry IoC se concentre sur l’injection de dépendances et ne tente pas de fournir une stack complète de développement comme le fait Spring. On ne trouve ni les Aspects, ni le pattern Template cher à Spring. Pour répondre aux besoins de programmation par aspect, Tapestry IoC propose des interceptors qui peuvent décorer les services. D’autre part, dans Tapestry IoC, l’injection est définie dans un ou plusieurs module(s) chacun d’eux pouvant contribuer à la configuration et aux services de l’application.

Dans ce premier article de la série Tapestry 5 qui commence aujourd’hui, nous verrons les bases de l’injection avec Tapestry IoC et les différences par rapport à Spring et Guice.

Lire la suite de cet article »