Débat : Quelles sont les limites du framework Web Apache Wicket ?
Confrontez vos points de vue

Le , par joseph_p, Membre expérimenté
Bonjour

Bien qu'appréciant beaucoup wicket, il n'en est pas moins que ce framework présente des limites. C'est d'ailleurs l'intitulé d'un post sur "Tom's Quest" : les limites de Wicket.

Les points évoqués sont (le détail sur le blog):
  • Le markup n’est pas toujours prévisualisable
  • Wicket ne tient pas la charge
  • Tester une application Wicket est difficile
  • Les URLs générées sont moches
  • Spring Security s’intègre mal à Wicket
  • Wicket n’est pas un framework managé
  • Wicket n’est pas outillé
  • L’intégrable avec des frameworks JavaScript est difficile


A noter que l'auteur ne fait pas que lister d'éventuelles limites, il en discute et les commente, allant parfois au final jusqu'à les rejeter. Toutefois, j'ai parfois des avis divergents, aussi je vais discuter ces points un à un.

Nous disions donc :
  • Le markup n’est pas toujours prévisualisable

certes, un Panel comprend une portion limitée d'html. Par conséquent, pas de vue d'ensemble avec un seul panel.

Toutefois, de mon expérience sur le sujet, le problème ne se pose pas ainsi.

En général, il y a d'abord une phase de maquettage, dans un format technologique assez simple afin que tout le monde puisse aisément communiquer sur le sujet (entre "product owner", designers et équipe IT). Une fois la maquette acceptée de part et d'autres, on passe alors à la partie implémentation dans la technologie cible.

Dans le cas de wicket, cela donne :
  • html très proche de celui rendu : pas de tag lib complexe où l'html résulte d'une part d'un tag, éventuellement dans un langage intermédiaire genre xml webxfform assez loin de l'html, d'une autre part du code "serveur" (Java,.Net...) et enfin de la page html elle même. De même, pas/peu besoin de modifier du code applicatif pour gérer les aspects de style et mise en forme : on est toujours dans l'html/CSS pur, très proche donc de la maquette et du langage des designer. De quoi simplifier grandement les échanges.
  • D'autres part, wicket permet de découper les différents éléments htmls ainsi que de les composer et/ou de les hériter. On compose donc vraiment une page structurée en différentes parties plus ou moins réutilisables. On peut donc etre au plus proche du principe "DRY/Don't Repeat Yourself", un peu de réflexion permettant d'éviter des copier/coller généralisés.
  • Enfin, et dans une certaine mesure en contradiction du premier point, les Behavior permettent de réaliser des décorateurs de composant. Tous vos buttons doivent avoir la classe CSS "btn" ? Facile, appliquez un SimpleAttributeModifier si le composant est de type Button. Actuellement, dans le projet sur lequel je suis, nous appliquons un Decorator générique qui est en fait une composition de différents décorateurs, chacun s'appliquant que lorsqu'il se doit. Bien sûr, ce décorateur générique est projet spécifique, permettant de varier le tout suivant les besoins. Et si jamais on se lance de l'ajouter à chaque composant, rien d'empêche d'étendre les composants utilisés, d'y faire l'addition du décorateur de façon systématique puis de les utiliser. En gros, le "server side" n'entre en action que pour éviter les répétitions et les risques d'erreurs.

Bref, pour conclure, une souplesse rare pour un framework web, permettant de gérer l'html comme il se doit : un problème de designer, navigateur et CSS, et aucunement une lutte contre des limitations arbitraires imposées par le framework "server side".

A noter que ces avantagent s'appliquent aussi au cas inverse d'utilisation d'un framework, lors de la maintenance. Modifier du html d'un projet dont on hérite la maintenance ne relève donc pas du travail d'hercule, du moins pour le coté serveur...

  • Wicket ne tient pas la charge


Sur ce point là, je renvoie toujours à la comparaison réalisée par Peter Thomas. Que peut on y constater ? Que wicket est parmi les mieux placés, même par rapport à un Tapestry 5 dont l'auteur dit s'être concentré sur les performances.

Wicket doit cela en grande partie, je pense, à la logique des IModel, et notamment du LoadableDetachableModel : ainsi, on peut gérer au mieux les objets, entre ceux récupérés de la DB qu'il ne vaut mieux pas persister dans la session (sauf pour l'id bien sur) et ceux qui doivent l'être (genre l'information d'état du moment).

Ceci dit, le "session bloat" existe. Malgré que les outils soient là (pour une fois aurai je envie de dire), on peut toujours mal s'en servir voir carrément s'en servir à contre sens. Mais cela relève plus de la compétence du développeur que du framework : aucun framework ne pourra se prévenir contre un mauvais usage.

  • Tester une application Wicket est difficile


Sur ce point là, j'aurai envie de répondre... oui, mais le problème est, je pense, général aux applications web, qui sont toutes tiraillées entre html, css, javascript, navigateur et l'oeil de l'utilisateur. Pas facile de s'assurer que tout ce petit monde fonctionne qui il devrait.

Wicket propose le WicketTester pour tester les pages en isolation, sans avoir besoin de recourir à un automate. Toutefois cela semble limité avec Wicket 1.4 (mais devrait évoluer avec 1.5). Combien même, toute la partie interactive, notamment via javascript, est sévèrement limitée.

D'autres approches, via selenium par exemple, ont toutefois émergées, comme celle proposée par Kent Tong dans Wicket Page Test : pour peu que vous injectez vos éléments "métier" comme il se doit, il propose un framework à même de fournir des données de test et de tester leur rendu via selenium.

Pour ma part, je dois dire qu'il s'agit d'un problème ardu : les pages web sont les composants les plus visibles d'une pile applicative, mais aussi les éléments que l'on touche souvent le moins (surtout quand on a un fort recours à la composition). Enfin, les pages web sont également difficiles à tester correctement (pas d'API et de contrat clairement défini à respecter).

La solution que nous appliquons actuellement se veut pragmatique. Vu que nous avons fortement recours à la composition via des composants dédiés à des fonctionnalités précises, nous joignions de façon quasi systématique des pages de test mettant en œuvre ces composants. Ces pages sont à chaque fois dédiées à une fonctionnalité précise et présentent les différents cas d'utilisation.

Elles permettent à la fois de montrer des exemples que de vérifier que des modifications ne viennent pas tout casser : elles sont vraiment un apport important à la rapidité et sureté de développement (plutôt que de devoir cliquer sur 15 liens de son appli pour enfin atteindre le composant XY sur lequel on travaille, le tout dans un contexte bien limité).

Lorsqu'un composant est particulièrement important (pour le login par exemple) ou fréquemment cassé/changé, on met alors en place des tests via selenium, afin de tester du coté utilisateur. Ces tests sont en fait intégrés via des tests unitaires, ils tournent donc ensuite sur le serveur d'intégration : la solidité des composants ainsi testés est impressionnante. Toutefois, cela implique une certaine charge de mise en place puis de maintenance (les tests doivent évoluer avec le composant) : nous n'appliquons cette solution qu'avec parcimonie.

  • Les URLs générées sont moches


Réponse facile : oui par défaut, mais ensuite on a énormément de choix pour avoir une stratégie qui correspond au plus près de nos besoins. Le wiki de wicket étant down suite à l'attaque récente d'Apache, voici une page du blog xebia introduisant les alternatives :
Readable url’s in Wicket – An introduction to wicketstuff-annotation.

De façon plus générale, le processus d'encodages/décodages des url est assez bien conçu pour permettre toutes les envies, si jamais les possibilités de wicket stuff ne sont pas suffisantes. L'HybridUrlEncodingStrategy, que nous utilisons, me semble d'ailleurs un excellent compromis en la matière de construction d'url A noter également, Wicket 1.5 a parmi ses objectifs une réécriture du code dédié à l'encodage/décodage des url afin de le rendre plus simple et plus souple. Bref, cela va encore s'améliorer !

  • Spring Security s’intègre mal à Wicket

Je n'utilise pas Spring Security, je ne peux donc pas commenter

  • Wicket n’est pas un framework managé


wicket n'a pas cédé à la mode (passée) du tout XML ou du tout "injection". Et comme le dit l'auteur du blog "c'est tant mieux" : wicket n'impose pas, il permet ! En effet, si vous voulez de l'injection de dépendance, wicket est ouvert à de nombreuses options et fait cela très bien. Perso, j'ai toujours été plus guice que spring, et l'intégration s'est faite sans soucis. En somme, plutot que de décider que vous devez utiliser tel framework d'injection de dépendances, tel format XML et tel technologie de persistence de données, wicket se contente de faire (très) bien la partie présentation et vous laisse libre champ pour le reste. Que du bonheur donc

  • Wicket n’est pas outillé


Oui, mais le besoin d'outillage n'est pas criant. Le fait d'être très proche de l'html puis que du java permet déjà de reprendre une bonne partie de l'existant. Au demeurant, le plugin eclipse wicket bench vient d'être repris par Laughing Panda. Qui sait, l'outillage serait peut etre plus complet un de ces jours ?

  • L’intégrable avec des frameworks JavaScript est difficile


De mon côté, nous utilisons beaucoup JQuery, et l'intégration se fait comme un charme. Seule précaution essentielle : laisser la partie Ajax à wicket. Pour le reste, intégrer des templates dans des composants wicket permet d'intégrer puis de réutiliser des composants JQuery de façon transparente en dehors du composant considéré. Simple et efficace. Là encore, au demeurant, la proximité de l'html avec celui qui est généré et utilisé côté client permet réellement une intégration simple et aisée.

A noter également que nous avons dû réaliser notre propre "framework" de gestion des dépendances vers les librairies javascript, s'appuyant sur un projet wicket stuff (ma mémoire me fait défaut pour le nom) afin d'utiliser des Content Delivery Network. Là encore, nous avons codé que peu de choses pour tirer le meilleur de ce qui est proposé actuellement

Voila pour ma réaction un poil exhaustive à cet article... J'espère ne pas m'être trop étalé...

Et, une autre fois, si le courage me revient, je me pencherai sur ma perception des forces (réutilisation via les composants, puissance de réalisation d'éléments web via la proximité avec le browser, l'html, le css et lejavascript, puissance de l'approche des IModel...) et faiblesses (quelques composants sont un cran en dessous des standards wicket, par exemple la modal window et le LinkTree, verbosité de Wicket, propertymodel non refactorisables...).

Au plaisir de vous lire !

++
joseph


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de joseph_p joseph_p - Membre expérimenté http://www.developpez.com
le 03/05/2010 à 21:48
Citation Envoyé par ymajoros  Voir le message
Citation Envoyé par joseph_p  Voir le message
Plus précisément, j'ai utilisé, en contexte professionnels, jsp, struts, velocity template, asp, asp.net plus du WebXForm. J'ai également étudié à titre perso jsf, tapestry 4, grails et wicket.

Bref, cela ne me semble pas relever d'un coup de tête dicté par une obligation de s'appuyer sur une JSR. Et je suis loin de m'arrêter là : GWT est le prochain sur la liste.

Ça me conforte dans mon idée.

j'ai du mal à suivre là : je dis en substance que j'ai utilisé/benchmarké de nombreux frameworks web avant de m'arrêter, depuis quelques temps déjà, sur wicket, et que ceci dit je continue ma veille sur le domaine. Aussi, cela conforte quelle idée au juste, celle du bricolage ?

En effet, connaitre les outils existants et savoir pourquoi on en choisit un plutôt que l'autre, en fonction de l'usage qu'on en attend, relève à mon sens d'une démarche raisonnée et raisonnable, loin de toute mode, coup de tête ou comportement digne de moutons de Panurge.

Pour ce qui est des performances, en terme de runtime, peter thomas a fait une comparaison assez poussée sur le sujet, je vous laisse la découvrir.

Si on parle de la robustesse et rapidité du développement, je crois que les atouts mis en avant plus haut devraient déjà donner une bonne idée des avantages de wicket, surtout qu'ils ne sont pas exhaustifs (l'internationalisation vient de me revenir en tête récemment, ainsi que le soin mis par l'équipe wicket pour adapter wicket à ses besoins, tout en hook et autres settings).

Évidemment, dur de "prouver" la chose, à chacun de se faire son avis en fonction de ses besoins, expériences et inclinaisons, mais pour cela il faut se donner la peine de réellement essayer et de vouloir en tirer le meilleur.

Et au final, nous pouvons tout à fait être en désaccord, la terre ne s'arrêtera pas de tourner pour autant, loin de là
Avatar de loic38_01 loic38_01 - Membre du Club http://www.developpez.com
le 05/05/2010 à 9:42
Avatar de Jimmy_ Jimmy_ - Membre éprouvé http://www.developpez.com
le 26/05/2010 à 15:18
Quelques nouvelles sur mon projet,

Wicket a passé une première étape de validation auprès des architectes qui sont maintenant très amicaux avec l'open source. (Les acheteurs aussi vu le prix de certains frameworks commerciaux).
Le but est quand même d'aller consulter un progiciel déjà très cher via son API Java et de réaliser une interface riche de visualisation à moindre coup.
Et Wicket a fait mouche, il reste un bémol, certains chefs de projet lui reproche sa philosophie anti-javascript. Ce n'est pas que l'on ne peut pas en faire, mais la validation de surface coté serveur n'est pas leur tasse de thé. Il me reste donc à démontrer qu'il est possible de faire des validations de surface javascript de manière simple.
Avatar de Ricky81 Ricky81 - Expert éminent sénior http://www.developpez.com
le 26/05/2010 à 22:04
Citation Envoyé par Jimmy_  Voir le message
Il me reste donc à démontrer qu'il est possible de faire des validations de surface javascript de manière simple.

Regardes du côté de Wicket Stuff l'intégration de Yav

Tu as également un billet de Zenika sur le sujet.
Avatar de joseph_p joseph_p - Membre expérimenté http://www.developpez.com
le 26/05/2010 à 22:57
Citation Envoyé par Ricky81  Voir le message
Regardes du côté de Wicket Stuff l'intégration de Yav

Tu as également un billet de Zenika sur le sujet.

tu as été plus rapide que moi, ouarf

ça me fait penser que je lirai bien ton avis sur les limites de wicket

concernant la demande initiale, quelles sont les motivations des dits architectes pour pousser la validation côté client ? Qui sait, cela peut aider à apporter d'autres éléments de réponses.
Avatar de Jimmy_ Jimmy_ - Membre éprouvé http://www.developpez.com
le 28/05/2010 à 9:39
Citation Envoyé par joseph_p  Voir le message
concernant la demande initiale, quelles sont les motivations des dits architectes pour pousser la validation côté client ? Qui sait, cela peut aider à apporter d'autres éléments de réponses.

C'est l'habituelle opposition de la charge serveur et réseau si pour une erreur de saisie basique on fait un appel serveur. J'ai pourtant prouvé qu'avec Ajax le flux est faible, les vieux poncifs sont encore présent.
Avatar de joseph_p joseph_p - Membre expérimenté http://www.developpez.com
le 31/05/2010 à 10:18
Citation Envoyé par Jimmy_  Voir le message
C'est l'habituelle opposition de la charge serveur et réseau si pour une erreur de saisie basique on fait un appel serveur. J'ai pourtant prouvé qu'avec Ajax le flux est faible, les vieux poncifs sont encore présent.

sur le fond, ils n'ont pas entièrement tort. L'argument peut difficilement être contré AMHA. Bref, faut espérer que Yav fasse l'affaire.
Avatar de joseph_p joseph_p - Membre expérimenté http://www.developpez.com
le 19/06/2010 à 23:39
en revenant sur le sujet initial du topic, j'ai récemment blogué sur le thème des tags libs et autres scriptlets, qui me font vraiment, au final, l'impression d'une fausse bonne idée. Plus par là : Pourquoi cet intérêt pour les scriptlets et autres taglibs ?
++
Avatar de el muchacho el muchacho - Membre régulier http://www.developpez.com
le 15/08/2010 à 8:49
ymajoros, tes arguments ne tiennent pas la route. Si on te suit, on devrait continuer à faire du Struts 1 ou des JSP à la main parce que c'est encore ce qui se fait le plus couramment, si on se base sur le nombre de posts rien que dans ce forum. Choisir un standard parce que c'est un standard, c'est simplement avouer qu'on est incapable d'en évaluer les mérites et les inconvénients.
C'est malheureusement le cas de nombre d'architectes qui ont choisi les EJB 1 ou 2, ou JSF 1. Ce n'est pas à cause des mérites respectifs de ces frameworks, mais bien parce qu'on a eu affaire à des gens qui n'avaient pas la compétence pour évaluer l'impact de ces frameworks sur les développements mais les ont quand même choisis pour se couvrir en cas d'échec.
On sait depuis longtemp que tous les standards ne sont pas bons, et Sun en a pondus quelques-uns qui ont eu le mérite d'exister mais se sont révélés bien médiocres à l'usage. Ce qui a permis l'existence d'une solution alternative nommée Spring que tout le monde considère comme supérieure aux EJB2.
Je ne dis pas qu'il faut jeter tous les standards, mais il faut savoir les évaluer comme tout le reste et les écarter s'ils ne procurent pas un avantage compétitif. Tu cites JPA comme standard. Il se trouve que la première version était mauvaise, et que la version actuelle est largement inspirée d'Hibernate (et pour cause, les auteurs d'Hibernate ont participé à son élaboration). Comme quoi...
Avatar de moez123 moez123 - Candidat au Club http://www.developpez.com
le 05/01/2011 à 11:40
J'ai utilisé wicket dans pas mal des projets et j'ai remarqué les avantages suivantes :
- Documentation riche
- forum (users@wicket.apache.org) tjrs actif
- pas de fichiers de configurations (comme struts-config...)
- un simple mapping java/properties/html sans config (juste le meme nom)
- est un framework d'apache
- plugin netbeans
- facile à intégrer avec spring, jpa, ejb3...
....

Et pour cela, j'ai vraiment adoré ce framework et meme j'ai commencé à ecrire des articles la dessus:
Avatar de Eric Taix Eric Taix - Membre à l'essai http://www.developpez.com
le 25/04/2012 à 22:16
Citation Envoyé par obourgeois  Voir le message

Ce qui serait interressant serait d'avoir un retour d'experience sur Vaadin, parceque d'après leur département marketing ça fait même le café

Il faut savoir tout de même que Vaadin s'appuie sur des composants GWT, et que donc on peut dire quasiment adieu aux templates HTML puisque tout est généré : l'interface se personnalise via des CSS, même si le framework semble laisser une possibilité d'utiliser un template HTML "en dur".

C'est assez vieux comme thread, mais oui prenez quelques heures pour tester Vaadin. Simple, efficace, personnalisable, bref c'est mon framework préféré du moment.

Comme retour d'expérience voici un lien d'une petite application que j'ai faite l'année dernière en full Vaadin: http://dot-art.cloudfoundry.com/

Aucune difficulté bien que que certaines fonctionnalités sortaient du cadre de Vaadin. Mais j'ai réussi dans difficulté à trouver la bonne façon de faire. A noter d'ailleurs que IT Mill édite un bouquin (gratuit) sur Vaadin et qui est extrêmement bien faire. J'avais essayé de faire la même application avec PlayFramework + JQueryUI et j'ai arrêté devant la difficulté (relative) où cela m'emmener (ancienne application visible sous http://dot-art.appspot.com/ : cette app sur GoogleApps ne fonctionne pas, c'est un proto et long au chargement car Google Apps décharge les applications quand elles ne sont pas utilisées...)
Offres d'emploi IT
Reconversion ingénieur informatique h/f
Adaming - Nord Pas-de-Calais - France
Community manager h/f
Adaming - Ile de France - Paris (75000)
Business Manager Energie (H/F)
Alten - Ile de France - Boulogne

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique Java : Mickael Baron - Robin56 -