Discussion :

[_dranece_]

Bonjour,

Je développe la partie UI d'un site grand public. Le site est assez volumineux (plus de cent pages dynamiques). On revend ce site à différents clients, on doit donc adapter le design au look du portail du client.
Actuellement on utilise Tiles pour décomposer les pages et factoriser les parties récurrentes ainsi qu'une librairie interne qui permet de générer des petits bouts de code (bouton ou input customisé).
Je souhaiterai aller plus loin en créant une librairie qui regrouperait l'ensemble des blocs et structures html. Ainsi, les pages jsp ne comporteraient plus de code html mais seulement un arbre dont les nœuds feraient référence aux composants de la librairie html et leur passerait différents paramètres ainsi que les données à insérer.
Il me semble que xml/xslt correspond à peu près à ce que je recherche mais je souhaiterait plutôt un framework qui effectue la transformation à la compilation un peu comme Tiles et qui n'ait pas d'impact sur les performances une fois les pages compilées. J'ai fait un essai avec Tiles mais les imbrications d'appel deviennent vite lourdes à gérer.

Si vous avez quelques pistes que je pourrai suivre, je suis tout ouïe et je vous remercie d'avance.

[kiwwi209]

Il me semble que FreeMarker ou Velocity gèrent très bien ce genre de choses et ont justement été écris pour permettre à chacun de "mieux" faire son job...
Ie : aux développeurs de faire du code et aux designers de gérer les couches graphiques.

[_dranece_]

Merci pour ces indications, je vais jeter un oeil à ces 2 frameworks. Mon but est effectivement de séparer au maximum le dev et l'ui ce qui permettrait de réutiliser plus facilement les éléments ui sans avoir à les réécrire lorsque la partie dev change.

[joseph_p]

Bonjour

Wicket devrait permettre de bien remplir les besoins: l'html est en effet séparé très proprement du code.

Les quelques tags wicket ne permettent pas d'écrire de la logique applicative, ce qui à mon sens est absolument nécessaire si l'on veut s'assurer qu'aucun développeur ne le fera.

Les tags servent uniquement à définir l'utilisation de chaque élément html : composition de composants, héritage de composants, tout cela est possible, tant avec les composants fournis par wicket que des composants écrits par soi même. En fait il n'y a aucune distinction entre les deux.

Ayant utilisé velocity par le passé, il y a à mon sens pas photo... De même pour les jsp, qui finissaient vite en "tag soup" sans parler de la logique applicative qui s'y trouvaient rapidement noyée.

Par contre, wicket ne permet pas de "pré génération" des pages, mais à ma connaissance cela n'a jamais posé de problème pour supporter de fortes charges. Il y a d'ailleurs ce test de performance : Perfbench. L'auteur du blog/test me semble une personne honnête (même si conquise par wicket, certes).

cordialement,
joseph

[_dranece_]

J'ai récupéré "Wicket in action", je vais y jeter un œil dès que j'aurai un peu de temps car j'ai un nouveau projet qui vient de tomber, je ne vais surement pas avoir le temps d'étudier ces différents framework avant au moins 1 bon mois.

Merci pour vos avis. J'essayerai de faire un retour de mes essais dès que j'aurai pu étudier ces différentes pistes.