Discussion :

[Jester]

Sinon pour ce que ça vaut :
rouge = java server faces
jaunes = spring mvc
bleu = struts 2



http://www.google.com/trends?q=strut...ate=all&sort=0

[Robert Bakic]

Perso, j'aime bien Azuki (www.azuki-framework.org), en même temps c'est moi qui l'ai fait !

[cyrille37]

Salut
Juste pour dire que ce serai bien que vous alliez découvrir Tapestry. C'est vraiment un très très bon framework. Il est très productif. Son gros défaut à mon avis c'est qu'il manque de docs bien faite pour faciliter sa prise en main.
Mais avec un p'tit effort, il vaut vraimement le coup.
Ca serait bien qu'il y ai plus de français qui s'y collent ;-)
Cyrille.

[sospoon]

Je confirme, il faut essayer Tapestry 5. Venant du monde J2SE/Oracle, j'ai récemment (début avril 2008) changé de job et je suis aujourd'hui architecte (et pour le moment unique développeur mais ça va vite changer) et je m'occupe de la création d'un site de commande en ligne.

Le client est un grand laboratoire pharmaceutique (connu de tous) et le site est à destination des pharmaciens et des médecins.

Mes contraintes :

--> le design des écrans a été réalisé par une agence de communication (la plus connue), est plutôt léché et fait sans qu'un "techos" ne bride l'enthousiasme des designers.

--> le temps de dev: même pas 2 mois pour:
modéliser une bdd qui valorise des commandes avec des conditions commerciales complexes
comprendre et migrer les données de l'ancien site (sauce struts + ERP vraiment bof)
developper et tester le site

--> Les performances: l'ancien site étant ce qu'on appelle communément dans le jargon une "daube" (et pourtant Dieu sait que j'essaie toujours de respecter l'existant mais là... 1min10 pour avoir accès à l'écran de commande de... 70 articles !!!)

Aujourd'hui, le pari (appelons un chat un chat) va être tenu (le gros fonctionne) et je tiens absolument à remercier Tapestry en version 5.11 (et aussi maven 2 sans qui je n'en serai pas là )

Pourquoi :
--> Il me fallait coller au plus près à ce que l'agence avait produit, et grace aux composants (Layout mon ami) et aux balises tml, j'ai pu rester dans qqchose que je connaissais bien, le html (ça a l'air comme les facelets de chez JSF)

--> Il fallait que j'optimise mon savoir J2SE à destination de la web app, et le fait de ne faire que du POJO m'a été d'un grand secours (en plus, si j'ai bien fait bcp de php y'a qques années, le coding dans la JSP ne me disait guère)

--> L'intégration de composants AJAX (script.aculo.us) pour :
la validation de formulaire (Ah... @Validate) + les regexp + les datefields
(quasiment uniquement ce dont j'avais besoin)

--> Grace à l'utilisation massive des @annotations et à l'absence d'XML de configuration, j'ai gagné un temps fou.

--> Les conventions de nommage sont tout le temps expliquées par HLS (le boss du projet) sur son blog, débattues et font souvent l'unanimité. Je les utilise sans avoir eu besoin de les determiner et cela me procure un gros gain de temps et apporte une vraie structuration à mon appli (vive l'archetype Maven).

--> Il va même être facilement possible de réutiliser le site en marque blanche car l'ajout de JS ou de CSS se fait aussi par @annotations dans le POJO

A cela on peut ajouter la facilité avec laquelle on peut implementer le patron de conception IOC (via l'annotation @Inject), la gestion des sessions (@ApplicationState), la persistence entre page (@Persist)...

Les désavantages:
--> Pas de doc... en français : mais j'ai habité 2 ans en Irlande alors ça va mais je comprends que cela puisse être rebutant
--> Si j'en lis vos descriptions, il me semble moins AJAX oriented que Wicket (que j'irais voir)

Les points en suspens:

--> Les performances me semblent très correctes mais il n'y a que 5 testeurs en parallèle. Wait & See (au pire on mettra des index de partout )
--> on va avoir un nouveau developpeur: aura t'il des difficultés à se l'approprier ?

J'espère que vous comprenez pourquoi j'ai voté Tapestry... en version 5.
Notez que je l'avais choisi après une longue comparaison...

Si vous avez des questions et que j'ai le temps, je n'hésiterais pas à vous répondre...

PS: Salut Robert, on a taffé ensemble, je vais aller voir ton framework, ça me changera de ton middleware

[skaalf]

Hello,

Je viens (moi aussi) de commencer à utiliser Tapestry 5 dans mon travail.

Avant de choisir ce framework, nous avons évidement essayé de se renseigner sur un maximum de framework.
Et la c'est la jungle, bon disons que les plus populaires sont:

- JSF
- Struts 1 & 2
- JBOSS Seam (basé sur JSF)
- Wicket
- Tapestry

Les contraintes été les suivantes:
- performance
- facile à integrer dans un (gros) projet existant, qui utilisait un peu Strut 1
- séparation forte entre le HTML et le code (un intégrateur nous fournit les pages HTML)

Struts 1 avait été une expérience douloureuse, Struts 2 semble intéressant, mais la migration de Struts 1 à Struts 2 paraissait périlleuse, en plus Struts 2 part un peu dans tous les sens (plusieurs systèmes de templates, plusieurs librairies de tag etc....)

JSF a un impact trop important sur le code HTML, il aurait fallut remplacer une grande partie du HTML par des tags JSF.
Les multiples implémentations de la spécification, pas toujours compatibles entre elles ne rassurent pas...

Seam est un peu un cas à part, c'est beaucoup plus qu'un simple framework MVC.

Nous avons donc hésité entre Wicket et Tapestry.

Wicket a l'air vraiment sympa, mais l'aspect complètement statefull aurait peut être posé des problèmes de perf.
L'impact vraiment faible sur le HTML est clairement un gros plus, par contre je trouve le code JAVA assez bordelique; Il faut gerer la hiérachie des composant, alors que cette hierachie et déjà présente dans le HTML, c'est un peu redondant non ?
Cet aspect rend le code vraiment verbeux.

Nous avons donc finalement essayé de passer à Tapestry.

On se heurte rapidement à un gros problème, la documentation est.... disons.... succinte
Par contre un fois qu'on commence à comprendre le principe, ça devient un bonheur.

Pour ce qui est du HTML, il est possible d'avoir la même chose que wicket, avec juste des t:id="toto" sur les élèments, ensuite une petite annotation dans le code java et c'est bon

Autre point fort, le framework est vraiment penser pour les perf (voir le cycle de vie de pages notamment).

Les composant son vraiment facile a créer (pas d'héritage comme dans wicket) et à utiliser.

Je n'ai pas encore tester l'AJAX.

Pour moi il reste un seul point noir, je n'ai pas trouver comment personnaliser le mapping des URL, qui sont par convention l'image de vos packages.

Exemple, la class toto.java se trouve dans fr.mondomaine.monprojet.pages.private, on atteint cette page en allant sur /private/toto

Voila c'était un peu long, j'espere que je vous ai donné envis d'essayer

Dernière chose, "Tapestry 5, building web application" par Alexander Kolesnikov est pas mal pour commencer.

Avoir les sources du projet (tapestry-core surtout) permet de comprendre rapidement le fonctionnement.

[benwit]

Avec ces deux derniers post, vous me donnez envie d'y jeter un oeil

[peuhhh]

Bonjour,

j'ai été séduit par l'approche de Jboss Seam, mais malheureusement je n'a pas eu le temp de me pencher plus dessus ( work oblige ), et il est vrai que j'aimerais le mettre en place sur un projet plus "personnel", auriez-vous un retour d'XP dessus ( pro / cons )

merci

[eracius]

Je me permets de rajouter mon avis de débutant autodidacte J2EE.

Après avoir commencé à regarder Struts et Tapestry, je me suis vite rendu compte que cette philosophie ne me convenait pas pour le développement.

J'ai préféré opter pour une architecture plus libre à base d'Ajax via DWR (qui s'appelle de la SOA si j'ai bien compris). Pour faire simple, DWR permet de présenter des objets java en javascript de façon transparente, il suffit d'appeler les fonctions souhaitées et traiter le résultat via une fonction callback (de l'Ajax quoi, mais sans s'occuper des HttpRequest).

Un exemple rapide pour ceux qui ne connaissent pas :

Java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
@RemoteProxy(creator = SpringCreator.class, 
		 creatorParams = @Param(name = "beanName", value = "maClass"))
class maClass {
 
	@RemoteMethod
	public Object maFonction(String param1, HttpServletRequest request){
 
	}
}

@RemoteProxy me permettant d'injecter un bean Spring via la classe SpringCreator (je travaille avec le combo classique Spring/Hibernate en dessous) mais ce n'est qu'une des solutions possibles.
L'objet HttpServletRequest permet d'avoir les informations de session et est automatiquement passé à chaque fonction.
On peut aussi se passer des annotations et utiliser le fichier dwr.xml (mais pourquoi faire compliqué ...)

Après configuration de DWR dans le fichier web.xml (très simple) et ajout d'un lien vers le fichier .js généré par DWR, on peut utiliser directement le bean dans javascript de cette façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
     maClass.maFonction(param1, maFonctionCallback);

Cette méthode demande de développer d'un côté le code métier java (où dans mon cas une couche qui fait le lien entre le code métier et DWR) et de l'autre un traitement javascript pour l'affichage des valeurs (des outils très pratiques sont fournis par DWR pour l'injection HTML). Une bonne organisation et de la rigueur sont donc nécessaires pour garder un code clair et propre (surtout côté javascript où c'est vite le souk). Le passage de paramètres de javascript->java peut aussi poser problème si on a besoin de passer des objets un peu compliquées (j'ai eu le soucis avec des list de list) mais ça se configure via le fichier dwr.xml.

La grande souplesse d'intégration est vraiment très agréable pour moi, surtout que j'ai besoin de réutiliser les mêmes objets dans plusieurs pages en modifiant juste le traitement callback sur les valeurs de retour. Mon application est sans aucun rechargement de page ce qui est plus agréable à mon sens pour l'utilisateur, qui oublie qu'il se trouve sur un navigateur (très important dans mon cahier des charges)

Après, je n'ai pas assez poussé mes investigations dans les autres framework pour vraiment pouvoir dire que mon choix est meilleur qu'un autre mais il me convient bien pour l'instant.

J'espère que ça pourra en éclairer certains sur une solution alternative

Edit : j'ai oublié de préciser qu'un couplage de DWR avec un framework orienté composant est complètement possible.

[oxylander]

Je participe à cette discussion intéressante :
je ne vais pas vous faire de la pub pour le meilleur selon moi, mais vous mettre en garde contre le pire framework de tous:
WebObjects d'Apple.
Totalement deprecated, mac de m... obligatoire, pauvre x-code de m... en guise d'EDI, un binding objet de la base à la mort-moi-le-noeud, j'en passe et des meilleures.
Un véritable enfer sur terre.
Il est possible de le faire tourner sur eclipse, grace à des courageux qui l'ont adapté (mais pas chez nous, 300Klignes à migrer). Mais à l'utilisation c'est pas glorieux.
En fait, j'ai l'impression qu'Apple l'a mis en OpenSource par manque de personnel pour le maintenir, et cerise sur le gateau: incompatible leopard.
Je souhaite bonne chance aux bleus-bite qui essayeront d'ajouter une image à leur projet en moins de 5h. Ou à ceux qui espèrent faire du sql pour taper leur base.
En bref les gars, si on vous parle de WO, passer votre chemin, en courant (c'est contagieux et honteux il parait comme maladie).

[nicorama]

Je suis assez sceptique à l'utilisation de Spring MCV et/ou Tapestry sur un point : faut-il mixer dans un seul framework la partie graphique (MVC) et la couche métier-database (EJB, persistence).

Les standards de Sun que sont JSF et JPA ont pour avantage de bien séparer le tout et d'être bon et complet pour les tâches qu'ils executent (même si JSF n'a pas forcemment des performances terribles).

Pour répondre à la question du débat : je n'utilise pas de framework. JSP (persistence écrite à la main) et Javascript (avec quand même Prototype) me suffisent amplement. Je compte néanmoins me mettre à JPA.

[Mascotte]

y a-t-il un IDE qui permet d'intégrer facilement Tapestry ou Wicket de manière assez intuitive pour la partie IHM ?

[djo.mos]

Je suis assez sceptique à l'utilisation de Spring MCV et/ou Tapestry sur un point : faut-il mixer dans un seul framework la partie graphique (MVC) et la couche métier-database (EJB, persistence).

Les standards de Sun que sont JSF et JPA ont pour avantage de bien séparer le tout et d'être bon et complet pour les tâches qu'ils executent (même si JSF n'a pas forcemment des performances terribles).

Euh ... je crains que tu te trompes sur ce coup là: ni Spring MVC ni Tapestry ne touchent à la couche persistence ou métier: ils ne touchent qu'à la partie présentation et contrôle.

[djo.mos]

y a-t-il un IDE qui permet d'intégrer facilement Tapestry ou Wicket de manière assez intuitive pour la partie IHM ?

Je ne sais pas pour Taperstry, mais pour wicket, comme la partie présentation est du pur HTML (enfin, presque), n'importe quel éditeur HTML ferait l'affaire, or tous les IDEs Java du marché (eclipse, NetBeans, IntelliJ, etc.) offrent un tel éditeur.

Sinon, y'a aussi WicketBench (plugin eclipse) qui permet de simplifier les opérations fréquentes de Wicket (générer page HTML + Page Java en une seule étape, regrouper l'éditeur Java/HTML, etc.) mais il n'est pas très à jour (parapport à eclipse et à Wicket).

Pour Netbeans, y'a WicketSupport qui offre des Wizards pour u nprojet Wicket, page Wicket et Panel Wicket.

[sospoon]

Je ne sais pas pour Taperstry, mais pour wicket, comme la partie présentation est du pur HTML (enfin, presque), n'importe quel éditeur HTML ferait l'affaire, or tous les IDEs Java du marché (eclipse, NetBeans, IntelliJ, etc.) offrent un tel éditeur.

même réponse pour Tapestry, c'est "presque" du pur html (du .tml pour tapestry markup language mais y'a une combine pour taffer en html) avec en plus les balises des composants Tapestry standards ou créés.

Par exemple, si tu as toujours le même block d'adresse dans une commande, tu créés le composant "adresse" en html, et tu l'appelles dans ta page avec la balise <t:adresse/> (t pour Tapestry).

[skaalf]

Exact, pour l'instant il n'y a pas (à ma connaissance) de plugin pour tapestry 5.

Mais en affectant la coloration des html aux fichiers .tml t'a deja la coloration syntaxique, la validation du xml (les composant tapestry doivent etre du xml valide), et les tags qui se referment tout seul (testé sous eclipse et netbeans).

Il manque que la completion en fait .

@Nicorama: Tapestry ne gère absolument pas la partie métier.
Pour chaque page web, tu creer un fichier .tml (xml avec le namespace de tapestry sur l'élément racine) et une classe Java (pur POJO, pas d'héritage)
Ensuite la classe java va te permettre de gerer les elements dynamique de ta page, mais tapestry ne gere absolument pas le métier.

Tapestry IoC te permet de découpler facilement la présentation du business

[djo.mos]

Tapestry IoC te permet de découpler facilement la présentation du business

En fait, c'est l'un des points retenus contre Taperstry: le fait qu'Howard, un excellent programmeur je dois avouer, mais qui réinvente la roue avec son HiveMind ... or dans d'autres frameworks on peut utiliser Spring (JSF, Wicket, Struts, etc.) ou Guice (Wicket, ...).

[skaalf]

Pas faux .

Je crois que tu peux quand même utiliser spring.
(http://tapestry.apache.org/tapestry5/tapestry-spring/)

[sospoon]

En fait, c'est l'un des points retenus contre Taperstry: le fait qu'Howard, un excellent programmeur je dois avouer, mais qui réinvente la roue avec son HiveMind ... or dans d'autres frameworks on peut utiliser Spring (JSF, Wicket, Struts, etc.) ou Guice (Wicket, ...).

Je ne suis pas d'accord, mais ça n'a rien à voir avec Tapestry, je tiens à le préciser pour ne pas me faire taxer de "chauvinisme

à partir du moment où on peut utiliser ou Spring ou Guice avec Tapestry, le fait de proposer un autre conteneur léger comme Hivemind (quoique c'est un peu différent le Tapestry Ioc), c'est donner "encore plus" le choix à l'utilisateur final. D'où l'existence des Pico, Azuki...

Sinon, on dit, tout le monde utilise Spring et on n'en parle plus. Je crois que cette concurrence est saine pour Spring lui même.

D'ailleurs, HLS explique qu'il reprend des idées de Guice mais il explique pourquoi il ne l'utilise pas.


Cette page explique la raison d'être de Tapestry IoC : http://tapestry.apache.org/tapestry5/tapestry-ioc/

Selon moi, cette concurrence est saine et positive

[PanzerKunst]

J'ai encore du mal à comprendre le but d'intégrer Spring à Wicket. Qu'est-ce que Wicket ne permet pas de faire (suffisamment bien) sans Spring ?

[djo.mos]

Rien justement
Je veux dire que wicket et Spring ne jouent pas dans la même catégorie : Wicket s'occupe de la partie présentation/contrôle, tandis que Spring est utilisé pour plein d'autres choses dans les autres couches (métier, daos, etc.):
- Conteneur de beans/injection de dépendances
- Pour la gestion des transactions
- Pour appliquer des aspects
- etc.