Discussion :

[cocula]

Bonjour,

J'en suis au tout début de ma découverte de Wicket et je n'ai même pas encore téléchargé le framework (pour le moment, je lis).

Je me pose la question suivante. Comment wicket fait-il pour utiliser une véritable page HTML comme template de vue ?
Est-ce qu'il parse systématiquement le html des templates qu'on lui fournit ? Si tel est le cas, n'est-ce pas une faiblesse ?

Personnellement, j'ai toujours pensé que le développeur n'avait pas à s'embêter avec HTML. Visiblement, les concepteurs de wicket sont partis du principe que le développeur n'est pas impacté car c'est le designer qui s'occupe de cette partie. Mais on sait très bien qu'en pratique c'est faut. Le designer conçoit en général des pages modèle que le développeur s'évertue à "recopier" pour créer ses vues.
Quand on utilise des jsp cela peut paraître l'enfer sauf si l'on est en mesure de créer une librairie de tags personnalisés qui permet d'éviter le codage du html directement dans la jsp.

Enfin, autre solution, la description des pages en XML, puis rendu à l'aide d'un moteur de templates (éventuellement XSLT) c'est pas mal non plus.

Alors, pour revenir à ma question initiale, est-il envisageable d'utiliser wicket en ne codant pas ses vues en HTML ?

[joseph_p]

salut

il me semble avoir déjà lu plusieurs fois des demandes sur la mailing list du genre "j'aimerai coder ma vue en xml, est ce possible" ou des trucs du genre, et la réponse est à chaque fois : c'est possible mais tout est à faire

Autrement dit, vouloir utiliser wicket sans son système de "template" html, c'est carrément pas recommandé...

Maintenant, sur l'intérêt ou non de la chose, voici mon point de vue, mais tu en fais ce que tu veux !

En quelques mots : wicket isole vraiment le code (et tous les traitements) de la vue html.

Le fait d'avoir à 90% des wicket:id dans les pages html résument bien la chose : toute la partie dynamique/code sera dans le Java correspondant. Pas de boucle faite dans la page jsp, ou de code métier au milieu de l'html.

Cela a une conséquence intéressante : les pages html générées sont très proches de celles utilisées pour coder.

Encore ce matin j'ai eu à appliquer un design réalisé par une personne extérieure à ma boite et franchement cela a été très rapide. Il faut juste savoir se retrouver dans les différents panel/composants que l'on a réalisé, mais cela ne doit pas être difficile et au contraire cela doit de toute façon refléter l'organisation de la page. Après, je rajoute juste les divers class="foo" qui vont bien et zou, roulez jeunesse

Au delà, cette proximité avec le html est aussi une force de wicket : après tout on fait bien du web là, et avec wicket tout ce qui est possible en html l'est aussi, sans avoir à passer par des composants hyper spécialisés. J'ai déjà eu à faire des choses très complexes, et cela s'est toujours avéré très simple : les design html complexes restent dans la page html et ne débordent pas dans le code

J'ai trop connu les moultes couches intermédiaires (XSLT, arg !!!) qui ne peuvent pas faire tout ce que fait l'html pour t'éviter chaudement la chose : tu auras vite besoin d'une fonctionnalité html particulière que tu ne pourras pas réaliser avec les composants proposés. Oh, pas grand chose, juste le petit truc qui te simplifierait grandement la vie

Bref, pour résumer, les wicket:id et autres éléments spécifiques à wicket (cf http://cwiki.apache.org/WICKET/wickets-xhtml-tags.html) permettent :
- de s'assurer que le code métier restera dans le code Java
- que toutes les richesses de l'html sont à portée de main
- de bien séparer les deux : le développeur et le designer seront tous les deux contents.

Seul défaut mineur évoqué, le découpage en composant que permet wicket fait que là où le designer ne voit qu'une page tu peux y voir 5 panels/wicket:container. Mais cela reste mineur à mes yeux et le tout semble pour moi la meilleure approche jusqu'à présent.

NB : tu parles d'un mode de développement inverse, cad là où le designer définit d'abord la page précisément puis le développeur intervient. Ca ne m'est pas arrivé souvent, hélas, de procéder ainsi, mais les rares où j'ai pu ça n'a été que du bonheur !!! Tout ce qu'il y à faire c'est à ajouter ces fameux wicket:id puis à découper le tout en petits bouts qui font sens. C'est vraiment top : nul besoin de torturer l'html pour le faire correspondre à je ne sais quel composant. Nul besoin de torturer je ne sais quel générateur/transformateur pour que le résultat de sortie corresponde au travail du designer. Non, on reprend tout tel quel et on ajoute les traitements serveurs. Du bonheur !

NB2, je suis un bavard après tout : par défaut, wicket conserve tous les attributs que tu mets à un tag html dans ton template. Comme ça ça peut paraitre anodin mais en fait c'est hyper puissant pour avoir des pages htmls hyper complexes en visu sans que cela ne dérange le développeur Java. Dans le même registre, les Repeater répètent le code html de ton choix, quelque soit sa nature, sans l'altérer (enfin, à part pour les parties dynamiques ajoutées via des wicket:id). Là encore ça peut semble anodin, mais en fait c'est génial : tu peux faire ton html sans te soucier de comment tu veux l'intégrer à ton code, vu que tu pourras ensuite t'y insérer ou le répéter à l'envie quelque soit sa nature

En toute franchise, les faiblesses de wicket seront plutôt à chercher, pour ma part, du coté :
- des modèles, pas toujours simples à comprendre/utiliser, même s'ils sont extrêmement puissant in fine
- de l'absence de Javascript côté client (pas de javascript pour y valider des choses par exemple, tout se fait via des retour au serveur, que ce soit ajax ou reload de page html classique) => tu peux le rajouter aisément dans les pages html, mais wicket ne le fait pas pour toi "out of the box"
- de l'ajax, dont le principe est génial (on code tout côté serveur, chaque action utilisateur provoquant un appel serveur), mais dont je ne suis pas certain de la robustesse pour l'instant (ceci dit une appli ajax intensive va bientot aller en prod, j'touche du bois ).

allez, j'espère ne pas t'avoir fait peur avec mon pavé

++

[djo.mos]

Salut,

Je me pose la question suivante. Comment wicket fait-il pour utiliser une véritable page HTML comme template de vue ?
Est-ce qu'il parse systématiquement le html des templates qu'on lui fournit ? Si tel est le cas, n'est-ce pas une faiblesse ?

Personnellement, j'ai toujours pensé que le développeur n'avait pas à s'embêter avec HTML. Visiblement, les concepteurs de wicket sont partis du principe que le développeur n'est pas impacté car c'est le designer qui s'occupe de cette partie. Mais on sait très bien qu'en pratique c'est faut. Le designer conçoit en général des pages modèle que le développeur s'évertue à "recopier" pour créer ses vues.

C'est un point de vue, partagée par une large portion même, d'où l'existence de pleins de frameworks où on touche pas à l'HTML (ou presque) : GWT, JSF, etc.

Wicket lui a pris l'autre voie : donner le contrôle total sur le HTML généré. Ca nécessite bien sûr qu'on sache manipuler le HTML, mais ça t'évite d'être frustré parcequel tel compoasnt de tel framework génère tel code HTML/CSS alors que toi tu veux le tweaker un peu.

Quand on utilise des jsp cela peut paraître l'enfer sauf si l'on est en mesure de créer une librairie de tags personnalisés qui permet d'éviter le codage du html directement dans la jsp.

Je ne te comprends pas là : JSP aussi manipule le HTML : Tu lmélanges des scriptlets avec de html dans une JSP. Wicket propose de faire de même, mais d'une façon plus propre dans la mesure où ta page HTML ne contient aucune logique/script/code/etc.

Pour les bibliothèques de tags de JSP, Wicket offre un mécansime pareil d'encapsulation/réutilisation qui est les composants. Sele différence, un composant Wicket est très simple à coder

Enfin, autre solution, la description des pages en XML, puis rendu à l'aide d'un moteur de templates (éventuellement XSLT) c'est pas mal non plus.

Ca me dégoute personnellement ... d'un côté avoir à sa main un langage turing complet et plus ou moins expressif qui est java, et ded l'autre côté utiliser un truc comme XSLT qui est tellement moins puissant et moins expressif que Java.

Alors, pour revenir à ma question initiale, est-il envisageable d'utiliser wicket en ne codant pas ses vues en HTML ?

théoriquement, Wicket est capable de travailler avec n'importe que type de markup du moment où c'est XML. A prendre avec des pincettes et à faire une recherche dessus pour confirmer? J4ai juste quelques souvenirs d'avoir lu quelque part des blogs où Wicket a été utilisé pour générer un flux RSS et un autre qui parlait de WML.

[cocula]

Je ne te comprends pas là : JSP aussi manipule le HTML : Tu lmélanges des scriptlets avec de html dans une JSP.

Il est tout à fait possible de coder en jsp sans écrire la moindre ligne de html. En développant ses propres tags qui jouent le rôle de composants et embarquent l'intégralité du code html.

Pour les bibliothèques de tags de JSP, Wicket offre un mécansime pareil d'encapsulation/réutilisation qui est les composants.

Ok, je n'ai pas encore bien exploré la partie composants de wicket.

Ca me dégoute personnellement ... d'un côté avoir à sa main un langage turing complet et plus ou moins expressif qui est java, et ded l'autre côté utiliser un truc comme XSLT qui est tellement moins puissant et moins expressif que Java.

XSLT est parfait pour transformer un "document structuré" (XML) en "document mis en forme" (HTML); il a été créé pour ça. Le problème c'est que le langage, qui utilise abondamment XPATH, est très complexe à maitriser, donc difficile à déployer à grande échelle.
L'utilisation d'un moteur de templates a par ailleurs l'avantage de faciliter un éventuel relooking de l'application.

Je travaille sur un progiciel de gestion (c'est à dire plusieurs miliers de pages) et par expérience la manipulation de HTML est un vrai problème pour la productivité des développeurs.
Autre problème, le long terme. Un progiciel métier doit changer de look périodiquement pour paraître plus attractif. Le relooking d'un tel progiciel est un énorme projet.

Je ne veux pas avoir l'air de râler. Il est normal d'avoir un regard critique. Wicket m'a l'air vraiment super bien, il n'y a que ce couplage avec HTML qui me froisse vraiment. Peut être que ma problématique serait mieux servie avec JSF (je ne connais pas encore) mais je crois par ailleurs que Wicket a de l'avenir car on entend déjà dire que JSF est trop "lourd". Ca rappelle un peu les arguments du débat EJB vs Spring.

[djo.mos]

XSLT est parfait pour transformer un "document structuré" (XML) en "document mis en forme" (HTML); il a été créé pour ça. Le problème c'est que le langage, qui utilise abondamment XPATH, est très complexe à maitriser, donc difficile à déployer à grande échelle.
L'utilisation d'un moteur de templates a par ailleurs l'avantage de faciliter un éventuel relooking de l'application.

Je travaille sur un progiciel de gestion (c'est à dire plusieurs miliers de pages) et par expérience la manipulation de HTML est un vrai problème pour la productivité des développeurs.
Autre problème, le long terme. Un progiciel métier doit changer de look périodiquement pour paraître plus attractif. Le relooking d'un tel progiciel est un énorme projet.

Je ne veux pas avoir l'air de râler. Il est normal d'avoir un regard critique. Wicket m'a l'air vraiment super bien, il n'y a que ce couplage avec HTML qui me froisse vraiment. Peut être que ma problématique serait mieux servie avec JSF (je ne connais pas encore) mais je crois par ailleurs que Wicket a de l'avenir car on entend déjà dire que JSF est trop "lourd". Ca rappelle un peu les arguments du débat EJB vs Spring.

Oui, désolé si mon ton était tranchant sur la question dans mon post précédent
Je suis d'accord, XSLT fait sa tache et il la fait bien, car il a été crée pour çà. Et je trouve que les points que tu cites sur la rapidité/simplicité de mises à jour sont valides.
Mais je reste toujours convaincu que :
- c'est moins puissant qu'un langage turing complet comme Java
- c'est simple pour les cas simples (lisez prévues d'avance) mais tordu pour les autres cas.

Perso, j'en suis arrivé à cet avis après avoir travaillé avec PHP (un peu et y'a longtemps), Struts, JSF et enfin wicket. J'ai aussi pas mal lu des articles sur Stripes, Tapestry, joué un peu avec Spring MVC, etc.

pour PHP, l'aspect pizza html/php était inadmissible. Mais les choses ont bougé avec l'arrivé en masse de frameworks MVC et autres.
pour Struts 1, j'avais pas aimé 2 choses : la lourdeur de la partie controller (hériter de ses classes, les ActionForm, le xml de configuration). J'avais aussi pas aimé les JSPs car à la base ça ressemble à PHP.
On peut toujours créer sespropres tags, mais leur création n'est pas très simple/rapide.

JSF, j'ai bossé sur 3 projets qui sont en production depuis plus d'un an + 1 de taille respectable pour mon PFE. Au départ, comparé à Struts, c'était une pûre doze d'air frais, avec les managed beans free-form (ou presque) et ses jeu de composants puissants (Richfaces entre autres).
C'est après que j'ai commencé à me casser les dents sur pleisnde problèmes par ci et par là. J'en parle dans mon blog si tu as le temps d'y jeter un coup d'oeil.

Mais pour résumer, avec le temps, j'ai de plus en plus de doutes sur les frameworks où il est question d'abstraction, ou plutôt où le niveau d'abstraction est très haut (JSF, les ORMs). Plus on s'éloigne des briques de base (html dans ce cas-ci), plus t'es limité par ce que le concepteur du framework a jugé utile de rendre configurable.
Ca te simplifie la vie la majorité du temps, mais quand on te demande une toute petite modification qui a l'air innocente, tu bloques complètement car t'as pas la main dessus.

Wicket me paraît un outils puissant pour générer du HTML (sa fonction de base) de façon propre et confortable. Il présente la dose correcte d'abstraction.

Mais attention, je ne dis pas que wicket est parfait. Zedros a déjà coté quelques points négatifs ladessus, et j'y ajouterais surtout le state-monster : wicket sérialise de façon transparente ce que dont il a besoin pour le rendu/restitution de la page. transparente == ça arrive sans que tu t'en rende compte, et si on code pas attentivement avec Wicket, ou qu'on code de façon intuitive, tu te retrouves avec des sessions géantes où des graphes complets d'objets sont persistés inutilement. Ca tiendrait pas la charge.

[cocula]

Merci pour tous ces conseils.

[joseph_p]

Il est tout à fait possible de coder en jsp sans écrire la moindre ligne de html. En développant ses propres tags qui jouent le rôle de composants et embarquent l'intégralité du code html.

En fait les panel/wicket:container sont des composants wicket qui encapsulent l'html et la partie java. Autrement dit, tu peux aussi aisément réutiliser des composants sans avoir à te soucier du Java ou de l'html.

XSLT est parfait pour transformer un "document structuré" (XML) en "document mis en forme" (HTML); il a été créé pour ça. Le problème c'est que le langage, qui utilise abondamment XPATH, est très complexe à maitriser, donc difficile à déployer à grande échelle.

Clairement tout dépend de ton cas d'utilisation. Si tu maitrises l'origine de tes pages (et que tu sais d'avance qu'elles n'auront rien de "fou fou"... chose pour laquelle je ne mettrai pas ma main au feu perso !) et que tu veux un processus automatique, alors certes wicket "out of the box" n'est pas suffisant.

Maintenant, concevoir des composants génériques pour générer des pages correspondant à des données bien structurées, cela me semble tout à fait possible.

Là où je serai plus prudent est pour les formulaires de saisie, qui impliquent gestion de la validation et des erreurs, que wicket fait très bien mais dont je vois mal comment on peut suffisamment généraliser la chose pour tout type de saisies...

A noter que précédemment j'ai travaillé dans une boite où le framework web maison était basé sur un mapping xml entre le code et la page. Il y avait une volonté de pouvoir changer de cible (web, RIA, client lourd) au besoin sans devoir changer la présentation.

Cela posait plein de problèmes pour exprimer des choses complexes, notamment sur la saisie de données (dépendances entre composants par exemple... cf les AbstractFormValidator pour voir une belle façon de gérer la chose) ou de l'html un poil plus innovant que les 3 modèles types de formulaire.

De même, lorsqu'un copain a eu comme projet top intéressant de porter une appli client lourd sur ce framework, il s'est vite trouvé confronté au souci qu'au final on ne peut pas faire du tout la même chose sur un client lourd que sur du web : pas de multithreading, problématique des différences entre navigateurs, taille des données envoyées chez le client...

Ils sont passés à XAML depuis, mais les problèmes demeurent : ajouter une abstraction entre la page html et le code est vraiment pénalisant, et l'idée d'avoir la même vue "traduite" différemment en fonction de la cible finale relève pour l'essentiel, à priori, du vœux pieu (essentiellement pour la saisie j'entends).

L'utilisation d'un moteur de templates a par ailleurs l'avantage de faciliter un éventuel relooking de l'application.

(...)
Autre problème, le long terme. Un progiciel métier doit changer de look périodiquement pour paraître plus attractif. Le relooking d'un tel progiciel est un énorme projet.

Il me semble que les CSS sont justement là pour ça non ? C'est d'ailleurs une des forces principales de cette techno Qu'as tu en tête sinon ?

Je ne veux pas avoir l'air de râler. Il est normal d'avoir un regard critique. Wicket m'a l'air vraiment super bien, il n'y a que ce couplage avec HTML qui me froisse vraiment. Peut être que ma problématique serait mieux servie avec JSF (je ne connais pas encore) mais je crois par ailleurs que Wicket a de l'avenir car on entend déjà dire que JSF est trop "lourd". Ca rappelle un peu les arguments du débat EJB vs Spring.

Pour le couplage avec l'html, je rejoins clairement djo.mos. Perso, j'ai tenté du velocity template, du .Net, du Tapestry 4.1, du grails, du php et un peu de JSF avant d'essayer Wicket, et franchement ce fut une révélation.

Je pense que souvent l'idée d'être proche de l'html fait peur car on pense de suite à du php ou des jsp avec javascript/tag et html imbriqués. Mais une page html wicket demeure elle toujours propre, sans code, cela enlève donc une grosse épine du pieds. De même, faire du web "directement" peut faire peur car cela rime avec complexité.

Certes, le web est complexe et riche en possibilité, mais pour s'en servir il vaut mieux avoir un outil qui en reflète les possibilités qu'un outil qui a une philosophie et des capacités bien différentes, car au final on en revient toujours à l'html... qui ne s'avère pas si dur in fine, quand on ne rajoute pas 15 couches côtés serveurs (entre l'accès aux données qui peut etre contraint, la couche métier qui est parfois une hydre sans nom, le fichier XML qui a ses propres règles, la transformation XSLT au milieu qui fait aussi des siennes...).