Les limites de Wicket: commentaire de texte

[joseph_p]

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

[Jimmy_]

Bonjour,
Je suis au support Java des equipes de developpement d'une grosse société.
Voici mon expérience sur ce framework :
Un aspect important est qu'il est 100% Java/Html et rien que ça. Ce qui lui autorise des montées en charge très rapide dans les équipes de développements néophites sur le framework. A l'opposé de JSF par exemple, qui nécéssite la compréhension de XML, JSF tag et JSF EL...
C'est un point important et une réduction des coûts non négligeable. Un développeur expérimenté en java est opérationnel en 1 semaine.

Voici un résumé de l'analyse que j'ai présenté à ma hiérarchie :

- Un framework J2EE sous licence open source Apache 2.0, orienté composant.
- Il ne nécessite que des connaissances en Java et Html.
- Permet une séparation complète du design et de la programmation : Il n’y a aucun tag de logique dans les pages et aucun code html ou javascript dans les objets java.
- Possède une politique d’authentification native.
- Framework sécurisé au niveau des URLs.
- Permet l’utilisation d’Ajax sans ajouter de javascript.
- La gestion de la session http est automatique sans aucune intervention du programmeur.
- Permet une costumisation des validations de formulaire via des objets spécifiques.
- Permet de créer et de réutiliser des composants.
- Gère automatiquement le bouton retour des navigateurs.
- Communauté Apache très active et réactive : plusieurs dizaines de messages par jour sur la mailing list.

J'ai aussi réalisé quelques exemples de pages, que je tiens à votre disposition sur demande.

[joseph_p]

Envoyé par Jimmy_

Je suis au support Java des equipes de developpement d'une grosse société.

Wicket a t il été retenu finalement ? Si oui, quels en sont les retours ?

Envoyé par Jimmy_

Voici mon expérience sur ce framework :
Un aspect important est qu'il est 100% Java/Html et rien que ça. Ce qui lui autorise des montées en charge très rapide dans les équipes de développements néophites sur le framework. A l'opposé de JSF par exemple, qui nécéssite la compréhension de XML, JSF tag et JSF EL...
C'est un point important et une réduction des coûts non négligeable. Un développeur expérimenté en java est opérationnel en 1 semaine.

A l'inverse il est parfois dit que wicket est assez pointu côté connaissances Java. Ce sentiment est il partagé de votre côté ?

Envoyé par Jimmy_

- Permet une séparation complète du design et de la programmation : Il n’y a aucun tag de logique dans les pages et aucun code html ou javascript dans les objets java.

hum, cela n'est pas tout à fait vrai, même si clairement pour un usage "standard" on ne met pas/voit pas d'html dans le code java.

Cela se complique dès qu'on intègre du javascript ou qu'on souhaite réaliser des behaviors élaborés (par exemple générer automatiquement les labels des inputs, en gérant notamment la notion de champ obligatoire)

A propos, je serai curieux de connaitre la mise en oeuvre concernant le partage d'éléments prédéfinis au sein d'un grand groupe. En effet, dans le cadre d'une petite équipe (<10 personnes), cela se fait assez aisément (même si déjà nous devons faire attention à communiquer régulièrement), je pense que cela peut se compliquer pour des équipes plus larges, à moins de minimiser les éléments communs/partagés, mais cela me semble peu désirable (et antinomique du choix de wicket).

[Jimmy_]

Envoyé par joseph_p

A l'inverse il est parfois dit que wicket est assez pointu côté connaissances Java. Ce sentiment est il partagé de votre côté ?

Oui, il faut une bonne compréhension du langage, puisque tout se fait en java. Une bonne structuration et l'utilisation des concepts objets est un gage de succes. Et heureusement, c'est même un des atouts de ce framework, java est au coeur du developpement et pas un passe-plat pour de la configuration xml ou des fichiers propriétaires.

Envoyé par joseph_p

A propos, je serai curieux de connaitre la mise en oeuvre concernant le partage d'éléments prédéfinis au sein d'un grand groupe.

Dans un grand groupe, l'uniformisation est une utopie, il existe une charte et des recommendations. Les applications passent des revues techniques auprès d'architectes, qui valident ou non les choix. Cela ne veux pas non plus dire que l'on fait ce que l'on veux. On assiste souvent à des réunions passionnées sur ces sujets. Le plus souvent une application ouvre la voie et des dizaines d'autres copient alors ces choix. On distingue donc des paquets d'applications sur le même modèle suivant les modes et les périodes.

Quand à la décision finale, elle n'est pas encore prise, mais sur la bonne voie. Je vous tiendrais de toute manière au courant.

[mc]

Il y a une alternative à Wicket, Vaadin de IT-MILL...un framework Web Java Open Source extraordinaire.
Faites un test, vous jugerez par vous même.

Une comparaison avec d'autres framework notamment Wicket.

[loic38_01]

J'utilise beaucoup Wicket depuis environ 1 an et demi.
Je trouve aussi que beaucoup des reproches de l'article de Tom's Quest ne sont pas justifiées, par exemple il est super simple de faire des montages de "belles url", comme ça par exemple :
mountBookmarkablePage("/customers.html", CustomersPage.class);

J'aime beaucoup l'approche composants et la séparation Java pur /HTML pur, qui facilitent grandement la maintenance et la réutilisation du code.
Pour faire de l'ajax c'est agréable de ne pas avoir de JavaScript à taper, même si l'intégration de librairies JS tierces demande un peu plus de connaissances du framework si on veut faire ça proprement.

Le point que je trouve parfois compliqué à gérer finalement avec Wicket est plutot lié à son aspect stateful, quand on l'utilise conjointement à JPA ou Hibernate (ou autre implem JPA)
Sur des écrans complexes avec beaucoup d'allers retours en Ajax, Wicket garde en mémoire les objets persistants, qui se trouvent alors détachés de la session hibernate. On se retrouve alors facilement avec des lazyloading exceptions.
Il existe des solutions avec le pattern session in view et les LoadableDetachable Model mais c'est une problématique qui peut rester assez compliquée à gérer...

[obourgeois]

• Spring Security s’intègre mal à Wicket

Oui et non. Réaliser une intégration complète me semble délicat, dans mon cas j'ai adopté pour une approche mixte :

- spring-security s'occupe de la couche authentification, du servlet filter et du redirect vers la page de login

- SWARM s'occupe de la couche authorisation dans mes pages et pour mes composants.

L'avantage c'est que SWARM est très bien intégré dans Wicket, l'inconvénient étant qu'il faut maintenir deux fichiers de configuration différents : celui de spring-sec et le fichier Hive de SWARM. Avec SWARM il devient possible de faire de l'affichage conditionnel de composants en mode déclaratif "à la JAAS"

HS : à titre personnel je n'ai pas été vraiment convaincu par spring-security que je trouve assez tordu à configurer et donc bien trop compliqué pour les trois quart des projets web.

Envoyé par mc

Il y a une alternative à Wicket, Vaadin de IT-MILL...un framework Web Java Open Source extraordinaire.
Faites un test, vous jugerez par vous même.

Une comparaison avec d'autres framework notamment Wicket.

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".

[obourgeois]

Sinon pour en revenir à l'article initial, les critiques me semblent taper un peu à côté de la plaque, et les réponses sont déjà faites dans l'article. Voici ce que je trouve comme faiblesses à Wicket :

• Wicket est verbeux, de plus son style assez proche de Swing n'arrange rien et peut en rebuter plus d'un. Une page pourtant simple peut comprendre énormément de petits composants (qui seront autant de déclarations Java) et de classes anonymes qui vont alourdir la syntaxe.
  
• Les PropertyModel, les Label dynamiques deviennent vite rébarbatifs à gérer. De plus, comme déjà dit, les PropertyModel ne sont pas facilement refactorables, même si des solutions sont en cours de recherche cf :
  
  http://wicketinaction.com/2009/11/re...code/#more-470
  
• L'introduction des génériques dans Wicket 1.4 peut amener de la complexité pour des développeurs débutants, ce qui est un peu dommage pour un framework ciblant la simplicité. Mais à vrai dire, ce point n'est pas vraiment spécifique à Wicket mais à tout projet utilisant des génériques.
  
• Wicket manque de bibliothèques de composants packagés et réutilisables, comme ce qui se fait dans le monde JSF. Il est toujours possible de les faire soit même, et c'est relativement simple, ou de se baser sur un des nombreux projets wicket-stuff (de niveaux très inégaux), mais c'est moins vendeur auprès d'une direction informatique
  

[joseph_p]

Envoyé par loic38_01

Le point que je trouve parfois compliqué à gérer finalement avec Wicket est plutot lié à son aspect stateful, quand on l'utilise conjointement à JPA ou Hibernate (ou autre implem JPA)
Sur des écrans complexes avec beaucoup d'allers retours en Ajax, Wicket garde en mémoire les objets persistants, qui se trouvent alors détachés de la session hibernate. On se retrouve alors facilement avec des lazyloading exceptions.
Il existe des solutions avec le pattern session in view et les LoadableDetachable Model mais c'est une problématique qui peut rester assez compliquée à gérer...

hum, cela mériterait un sujet à part entière je trouve. En effet, les possibilités sont nombreuses et, d'ailleurs, relèvent plus des problématiques liées à toutes implémentations JPA je pense. A mon boulot nous avons étudié plusieurs approches, et je suis plutôt satisfait de la solution actuelle, même si au final ce problème d'ORM et de couche de persistance est intrinsèquement compliqué, surtout s'il l'on veut supporter tous les usages possibles (long running transaction notamment).

Je serais réellement intéressé d'en discuter plus avant, par exemple d'une approche consistant à avoir un modèle s'assurant que les entités déjà persistantes sont toujours attachés à l'Entity Manager courant (modèle bien sympathique qui fait que les Lazy Loading Exceptions sont tout simplement inconnues chez nous...).

concernant le problème de l'Ajax et des mises à jour du modèle, il y a là, je pense, un vrai problème de fond concernant wicket : certains composants type AjaxFormComponentUpdatingBehavior mettent à jour le modèle avant même la soumission du formulaire courant, ce qui est très dangereux vis à vis de l'approche "classique" de wicket consistant à mettre à jour le modèle en une seule fois, lors d'une soumission n'ayant entrainée aucune erreur de validation.

De façon plus pragmatique, il faut aussi bien avoir en tête que tout formComponent ne devrait publier son état que lors de l'appel "updateModel()" (cf IFormModelUpdateListener et, par exemple, le blog d'Igor sur le sujet Building a ListEditor form component).

Là encore, au besoin, je suis plus que prêt à développer, sachant de toutes façons que cela fait quelques temps que je me dis que je devrai en parler sur la ML wicket.

Envoyé par obourgeois

[*] Wicket est verbeux, de plus son style assez proche de Swing n'arrange rien et peut en rebuter plus d'un. Une page pourtant simple peut comprendre énormément de petits composants (qui seront autant de déclarations Java) et de classes anonymes qui vont alourdir la syntaxe.

hum, je suis entièrement d'accord pour le côté verbeux. Quelqu'un aurait il essayé Wicket + Scala, qui semble être la combinaison idéale pour réduire cette verbosité à l'essentiel ?

Envoyé par obourgeois

[*] Les PropertyModel, les Label dynamiques deviennent vite rébarbatifs à gérer. De plus, comme déjà dit, les PropertyModel ne sont pas facilement refactorables, même si des solutions sont en cours de recherche cf :

http://wicketinaction.com/2009/11/re...code/#more-470

je me demande aussi dans quelle mesure le "meta modèle" descriptif des entités sauce JPA2 ne devrait pas pouvoir être mis à profit. A creuser un jour où j'aurai plus de temps lol

Envoyé par obourgeois

[*] Wicket manque de bibliothèques de composants packagés et réutilisables, comme ce qui se fait dans le monde JSF. Il est toujours possible de les faire soit même, et c'est relativement simple, ou de se baser sur un des nombreux projets wicket-stuff (de niveaux très inégaux), mais c'est moins vendeur auprès d'une direction informatique

clair, j'irai même un peu plus loin : des composants comme le TreeLink actuels sont parfois excessivement complexes, et à l'extrême la ModalWindows s'avère bien dure à mettre en œuvre sans mauvaise surprise. En somme, certains composants faisant partie du noyau de Wicket ne sont pas des plus optimaux.

A l'inverse, le gros atout de wicket est de réellement permettre de créer des composants riches et complexes collant au plus près du besoin. Tout y est personnalisables (via notamment des surcharges) et l'ensemble des possibilités de l'html sont accessibles. Dès lors il devient difficile de réaliser un composant qui soit à la fois suffisamment générique pour chaque développeur wicket y trouve son compte tout en restant simple.

sur le fond, toutefois, je tends à penser que cette approche est la bonne : en interne à une entreprise, on peut aisément créer des composants réutilisables collant à la réalité des besoins, bien loin de toutes ces batailles de customisation ou de restrictions de GUI du fait de limites de composants issus d'une librairie.

[ymajoros]

Pour moi, la limite principale est qu'il n'y a pas de standard derrière.

[joseph_p]

Envoyé par ymajoros

Pour moi, la limite principale est qu'il n'y a pas de standard derrière.

standard comme une JSR derrière le framework lui même ? Autrement dit, les seules options pour faire du web en java serait JSP ou JSF, sommes nous d'accord ?

là en effet wicket ne peut rien faire, mais s'il y a obligation de JSR pour les frameworks utilisés, le choix est restreint d'office et considérer Wicket ne fait pas sens...

La première étape serait à mon sens de se demander si cette restriction fait sens et, si oui, de ne pas regarder ailleurs. Mais c'est un autre débat

[loic38_01]

Envoyé par joseph_p

hum, cela mériterait un sujet à part entière je trouve. En effet, les possibilités sont nombreuses et, d'ailleurs, relèvent plus des problématiques liées à toutes implémentations JPA je pense. A mon boulot nous avons étudié plusieurs approches, et je suis plutôt satisfait de la solution actuelle, même si au final ce problème d'ORM et de couche de persistance est intrinsèquement compliqué, surtout s'il l'on veut supporter tous les usages possibles (long running transaction notamment).

Je pense que le problème est particlièrement compliqué avec Wicket à cause du côté stateful, qui n'est pas forcement le plus adapté pour les appli web (mais là con peut partir dans un grand débat...)
Avec un framework orienté requetes comme Play! framework, où le serveur oublie tout apres chaque requete, on n'a pas ce genre de soucis. Les objets sont soit manipulés côté clients (json, local storage ou autre), soit rammenés de la base le temps d'une requete et on n'a jamais de problème de lazy et on ne réfléchie pas à l'état des objets stockés dans la session...

Envoyé par joseph_p

Je serais réellement intéressé d'en discuter plus avant, par exemple d'une approche consistant à avoir un modèle s'assurant que les entités déjà persistantes sont toujours attachés à l'Entity Manager courant (modèle bien sympathique qui fait que les Lazy Loading Exceptions sont tout simplement inconnues chez nous...).

Alors là ça m'intéresse, si tu as une manière élégante de faire ça je veux bien que tu m'en dises plus!

[ymajoros]

Envoyé par joseph_p

standard comme une JSR derrière le framework lui même ? Autrement dit, les seules options pour faire du web en java serait JSP ou JSF, sommes nous d'accord ?

On peut toujours bricoler avec les multiples frameworks qui vont et qui viennent... Mais certainement aujourd'hui, je ne prendrais pas un framework juste parce que je l'aime bien, sans standard derrière qui m'assure une certaine pérennité, à moins d'avoir une bonne raison. Je serais curieux de savoir.

Envoyé par joseph_p

là en effet wicket ne peut rien faire, mais s'il y a obligation de JSR pour les frameworks utilisés, le choix est restreint d'office et considérer Wicket ne fait pas sens...

C'est ce que je pense. Utiliser Wicket ne rend pas plus efficace que de faire du JSF, mais on est sûr de rester coincé avec une seule implémentation.

[Killing Joke]

Envoyé par ymajoros

C'est ce que je pense. Utiliser Wicket ne rend pas plus efficace que de faire du JSF, mais on est sûr de rester coincé avec une seule implémentation.

Cette histoire de "rester coincé avec une seule implémentation" : c'est aussi ce que j'entends sans arrêt dans ma boîte.

Et franchement au bout d'un moment çà saoule un peu comme discours, parce que dans une grande majorité de cas, c'est se poser des questions qu'on n'a pas à résoudre.

Que dans certains cas on jongle avec des implémentations (tests) ou qu'on mette des surcouches d'homogénéisation (encapsulation des loggers), pas de soucis, plus des cas de paramétries et de modifications de comportements.

Maintenant qu'on veuille à tout va pouvoir *tout* remplacer par une autre implémentation (la couche DAO complète, un framework complet, etc.) ... ben je trouve juste çà stupide. Franchement. Si çà peut être séduisant sur le papier, c'est vraiment de l'intellectualisation à outrance : en pratique, sur un projet, qu'il soit court ou qu'il reste sur la durée, çà n'arrive pratiquement jamais. Ben oui, pour remplacer un tel élément par un autre, il faut déjà une sacré bonne raison. Ca prendra de toutes façons du temps. Et surtout il faut que ce par quoi on fait le remplacement respecte la même implémentation : autrement dit, ait exactement les mêmes fonctionnalités, donc au final, on change juste une réalisation par une autre, ce qui en général, sauf gros plantage initial pas détecté à temps (perfs Hibernate catastrophiques, etc.), ne sert strictement à rien. Et si jamais par le plus grand des hasards 5 ans après le démarrage du projet il faut remplacer quelque chose par autre chose, ce sera de toutes façons du boulot, et il y aura de toutes façons des évolutions techniques et fonctionnelles à appliquer avec, donc autant se poser la question le jour J.

Il y a des jours où rester pragmatique ne fait pas de mal, je trouve ...

Après qu'on veuille se reposer sur un standard, je le conçois très bien, mais plus pour d'autres raisons : capacités à trouver de la documentation, du support ou des compétences sur ce sujet (il y plus de gens formés à JSF qu'à Wicket sur le marché) par ex.

[joseph_p]

il est tard, il est dimanche soir, je vais faire court :$

Envoyé par loic38_01

Je pense que le problème est particlièrement compliqué avec Wicket à cause du côté stateful, qui n'est pas forcement le plus adapté pour les appli web (mais là con peut partir dans un grand débat...)
Avec un framework orienté requetes comme Play! framework, où le serveur oublie tout apres chaque requete, on n'a pas ce genre de soucis. Les objets sont soit manipulés côté clients (json, local storage ou autre), soit rammenés de la base le temps d'une requete et on n'a jamais de problème de lazy et on ne réfléchie pas à l'état des objets stockés dans la session...

Clairement, si faire stateless/REST fait partie des objectifs, ne pas partir sur wicket

Ceci dit, pour moi, le statefull est un réel plus, permettant de gérer plus aisément des problèmes complexes, notamment en termes d'UI, ce qui est le cas de bien applications internet.

Quand à mettre cette gestion de l'état du côté client, dans un contexte web html/css/javascript, cela soulève bien des problèmes que je préfère éviter :
- sécurité (code exécuté sur le client, donc visible et modifiable pour qui s'en donne les moyens)
- diversité des navigateurs et des paramétrages clients.

Envoyé par loic38_01

Alors là ça m'intéresse, si tu as une manière élégante de faire ça je veux bien que tu m'en dises plus!

avec plaisir, mais une autre fois.

Envoyé par ymajoros

On peut toujours bricoler avec les multiples frameworks qui vont et qui viennent... Mais certainement aujourd'hui, je ne prendrais pas un framework juste parce que je l'aime bien, sans standard derrière qui m'assure une certaine pérennité, à moins d'avoir une bonne raison. Je serais curieux de savoir.

Bricoler... merci ! Passons.

Je ne comprends pas cet intérêt pour un standard utilisé dans le sens "standardisation sauce JSR". Les EJB 2 étaient un standard, fallait il les utiliser pour autant ? Au delà, un développement EJB 2 est il pérenne à l'heure actuelle ?

L'argument du standard ne se suffit pas à lui tout seul. Il faut creuser plus loin.

En l'occurrence et en quelques mots, concernant wicket donc, ce dernier est statefull, orienté composants, doté d'une forte communauté (mature qui plus est, notamment en matière de versionning) , non limitatif en termes de possibilité html/css/javascript, très bien séparé entre Java et html afin de rendre le tout plus aisé (maintenance et développement) et performant.

Bref, cela fait plus d'une bonne raison à mon sens, qui n'engage que moi certes

Au delà, je ne sais pas comment a été réalisé le choix de JSF, mais pour ma part j'ai longuement comparé/utilisé/creusé mon choix de framework web avant de me poser sur wicket.

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.

Envoyé par ymajoros

C'est ce que je pense. Utiliser Wicket ne rend pas plus efficace que de faire du JSF, mais on est sûr de rester coincé avec une seule implémentation.

sur quoi s'appuie cet avis que Wicket ne rend pas plus efficace que faire du JSF ? Dans tous les cas, cela a t il le moindre lien avec le fait que JSF soit un standard ?

quand au problème d'une seule implémentation, Killing Joke a déjà très bien répondu. Et je rajouterai que toutes les implémentations du monde n'ont jamais fait des EJB 2 une réussite...

[ymajoros]

Envoyé par Killing Joke

Cette histoire de "rester coincé avec une seule implémentation" : c'est aussi ce que j'entends sans arrêt dans ma boîte.

Et franchement au bout d'un moment çà saoule un peu comme discours, parce que dans une grande majorité de cas, c'est se poser des questions qu'on n'a pas à résoudre.

Je pense que tu as tort, je ne pense pas poser de questions inutiles à ce sujet. Utiliser le standard n'est pas plus difficile.

Envoyé par Killing Joke

Que dans certains cas on jongle avec des implémentations (tests) ou qu'on mette des surcouches d'homogénéisation (encapsulation des loggers), pas de soucis, plus des cas de paramétries et de modifications de comportements.

Je trouve que si les surcouches ne sont pas standard, on ne gagne rien (je déteste le "clogging", comme disais l'autre).

Envoyé par Killing Joke

Maintenant qu'on veuille à tout va pouvoir *tout* remplacer par une autre implémentation (la couche DAO complète, un framework complet, etc.) ... ben je trouve juste çà stupide. Franchement. Si çà peut être séduisant sur le papier, c'est vraiment de l'intellectualisation à outrance : en pratique, sur un projet, qu'il soit court ou qu'il reste sur la durée, çà n'arrive pratiquement jamais. Ben oui, pour remplacer un tel élément par un autre, il faut déjà une sacré bonne raison. Ca prendra de toutes façons du temps. Et surtout il faut que ce par quoi on fait le remplacement respecte la même implémentation : autrement dit, ait exactement les mêmes fonctionnalités, donc au final, on change juste une réalisation par une autre, ce qui en général, sauf gros plantage initial pas détecté à temps (perfs Hibernate catastrophiques, etc.), ne sert strictement à rien. Et si jamais par le plus grand des hasards 5 ans après le démarrage du projet il faut remplacer quelque chose par autre chose, ce sera de toutes façons du boulot, et il y aura de toutes façons des évolutions techniques et fonctionnelles à appliquer avec, donc autant se poser la question le jour J.

Ce n'est simplement pas vrai, une bonne utilisation du standard permet de changer rapidement d'implémentation. J'ai eu à le faire, sans trop de dégâts et rapidement. Les changements sont en général les morceaux qui étaient restés spécifiques à une implémentation.

Envoyé par Killing Joke

Il y a des jours où rester pragmatique ne fait pas de mal, je trouve ...

Après qu'on veuille se reposer sur un standard, je le conçois très bien, mais plus pour d'autres raisons : capacités à trouver de la documentation, du support ou des compétences sur ce sujet (il y plus de gens formés à JSF qu'à Wicket sur le marché) par ex.

Dans la plupart de mes projets, je ne changerai pas d'implémentation. Mais dès le début, je sais que je peux me reposer sur un standard, avec les avantages que tu cites en fin de message. Ce n'est pas que je veux pouvoir changer ma couche de persistance toutes les deux semaines. Note que si j'ai à le faire, je ne vois pas pourquoi ça devrait être compliqué.

Ex. : j'utilise JPA pour ma couche de persistance. Ce n'est pas plus compliqué que d'utiliser des API propriétaires (Hibernate, Eclipselink, ...), et ça m'apporte plus ou moins les mêmes choses. Mais j'ai des garanties que je n'aurais pas autrement : le comportement de l'implémentation doit suivre le standard, et c'est bien de ça que je discuterai avec les développeurs en cas de problème. Dans ce cas, pas besoin d'API propriétaire dans la plupart des cas.

Je trouve que même s'il n'y a que l'implémentation de référence, on gagne à utiliser le standard.

[obourgeois]

Moui, cette histoire de standard / pas standard, c'est un vieux débat qui n'en finira jamais et ce n'est à mon avis pas le bon angle d'approche pour choisir un framework web. Je pense que les seules bonnes questions à se poser sont :

• le framework va-t-il vraiment nous simplifier le développement ? (et pas juste nous prendre du temps de formation)
• pourra-t-on tenir le cahier des charges avec ce framework ?
• dans le cas d'un framework open-source, est-ce qu'il y a une communauté derrière pour corriger les bugs et pousser des évolutions ?

Les réponses à ces questions dépendent du cahier des charges du projet, du budget, des compétences de l'équipe de développement, et donc le choix du framework variera d'autant. Des fois Wicket sera un excellent choix, et des fois un très mauvais choix. C'est à vous de choisir et ensuite de faire un bilan honnête pour mieux situer les cas d'utilisation. Malheureusement les débats sur les frameworks sont souvent le theâtre de guerres de religion et d'egos ou chacun défend son choix en évitant soigneusement de se remettre en question.

Mais bon, je trouve assez piquant d'utiliser JPA comme exemple de standard sachant que les premiers jets (JPA1, JDO) n'ont jamais vraiment convaincu les développeurs qui ont massivement utilisé un outil nommé Hibernate et qui n'était absolument pas standardisé.

Maintenant Hibernate implémente JPA2 (comme EclipseLink par exemple), mais la standardisation me semble plus être une conséquence du succès qu'un préalable.

[ymajoros]

Envoyé par joseph_p

Je ne comprends pas cet intérêt pour un standard utilisé dans le sens "standardisation sauce JSR". Les EJB 2 étaient un standard, fallait il les utiliser pour autant ? Au delà, un développement EJB 2 est il pérenne à l'heure actuelle ?

(Je crois qu'on risque de déborder du sujet, mais si le coeur vous en dit ;-) )

Qu'est ce que tu veux dire par "standardisation sauce JSR" ? Je ne veux pas spécialement dire dans ce sens, mais en Java, c'est bien un standard. On utilise souvent le mot "standard" pour dire "habituel", il y a pourtant une grosse différence. Wicket n'est pas standard, par exemple.

Une application EJB2 continue à tourner sur les serveurs EJB3. EJB3 n'est qu'une simplification. Je pense que les EJB2 étaient un framework intéressant mais compliqué. Les différents processus ont fait que le standard a évolué. Pas parce qu'un développeur a vite codé quelque chose, plutôt parce qu'un comité d'experts a pris la peine de réfléchir.

Envoyé par joseph_p

En l'occurrence et en quelques mots, concernant wicket donc, ce dernier est statefull, orienté composants, doté d'une forte communauté (mature qui plus est, notamment en matière de versionning) , non limitatif en termes de possibilité html/css/javascript, très bien séparé entre Java et html afin de rendre le tout plus aisé (maintenance et développement) et performant.

Je trouve tout ça attirant... mais je continue à penser qu'à moins d'un besoin spécifique non couvert par un standard, il vaut mieux s'en passer. Que des librairies développés hors standards soient développées plus rapidement et aient plus de possibilités, j'en conviens. Mais ce modèle offre moins de garantie.

Envoyé par joseph_p

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.

Envoyé par joseph_p

sur quoi s'appuie cet avis que Wicket ne rend pas plus efficace que faire du JSF ? Dans tous les cas, cela a t il le moindre lien avec le fait que JSF soit un standard ?

Sur quoi s'appuierait un avis contraire ? ;-)

Sans comparaison définitive (ça existe ?), je choisis le standard.

Envoyé par joseph_p

quand au problème d'une seule implémentation, Killing Joke a déjà très bien répondu. Et je rajouterai que toutes les implémentations du monde n'ont jamais fait des EJB 2 une réussite...

Je ne suis pas sûr que les EJB 2 n'ont pas été une réussite. Combien d'applications ont vu le jour en EJB 2 ? Combien en wicket ? Je n'en ai aucune idée. Je ne dis pas que Wicket n'est pas plus élégant, ce n'est pas ce qui compte le plus à mon avis.

[ymajoros]

Envoyé par obourgeois

Mais bon, je trouve assez piquant d'utiliser JPA comme exemple de standard sachant que les premiers jets (JPA1, JDO) n'ont jamais vraiment convaincu les développeurs qui ont massivement utilisé un outil nommé Hibernate et qui n'était absolument pas standardisé.

Maintenant Hibernate implémente JPA2 (comme EclipseLink par exemple), mais la standardisation me semble plus être une conséquence du succès qu'un préalable.

Je pense que tu fais erreur. JPA 1 a été massivement utilisé, une recherche google te le montrera. Et Hibernate implémentait JPA 1.

Là où je te rejoins, c'est qu'avant JPA, Hibernate existait déjà, avec une API propriétaire (qui existe toujours, en parallèle). Et ce n'était pas le seul : ici, on utilisait Toplink (maintenant Eclipselink), qui existe depuis 10 ans.

Avec JPA, on a gagné en clarté et support (il est souvent plus facile, si on soupçonne un bug, de voir ça comme une non-conformance au standard, en général vite corrigée). Et par ailleurs, on peut switcher d'implémentation facilement : si ce n'était pas notre but, ça fonctionne sans problème et nous a permis d'évaluer facilement si ça valait la peine de changer ou pas (et Hibernate est loin d'être le seul choix possible, crois-moi).

[joseph_p]

Bonjour

Si certains trouvent que Wicket a pour limite de ne pas être un standard, que ce soit dans le sens "issu d'une standardisation" ou "standard de fait car utilisé partout", alors oui il s'agit de 2 limites de Wicket, clairement.

Quand au débat qui en découle, à savoir "faut il n'implémenter que des standards oui ou non", je pense vraiment qu'il faudrait mieux le mener ailleurs que dans le sujet actuel. Aussi, svp, créez un sujet approprié.

Je continuerai le reste de la discussion plus tard, j'intervenais surtout pour éviter que ça ne dégénère trop

++