On le voit aussi sur nos projets, la doc c’est un sujet sensible (car nécessaire) mais chronophage (donc souvent sous-estimé)

Ensuite, concernant l’arrogance des leads developers (et peut être moi aussi parfois), c’est souvent des problèmes de communications. Le fait de s’approprier quelque chose, nous atteins directement quand quelqu’un le critique.

Je n’ai jamais essayé Stripes (d’ailleurs faut que je trouve le temps de regarder ça prochainement), mais je trouvé en Wicket, le Framework Web Java qui me permet de développer rapidement, simplement et de façon élégante des applications évoluées tout en prenant du plaisir à le faire. Ce que je n’avais pas ressenti depuis fort longtemps (la faute à Struts et à JSF).

Un framework trouvera son public naturellement. Il ne pourra pas fédérer tout le monde. Ceux dont la déception sera trop grande aura vite fait de le critiquer, cependant il n’en reste pas moins un très bon framework, qui si il s’améliore sur ses points faibles, risque bien de devenir un grand framework.

Je développe sur la plateforme J2EE depuis 2002 et j’ai manipulé de près ou de lien tout ce qui existe en terme de framework web.

Personnellement, je trouve que wicket comme stripes sont ce qui se fait de mieux dans ce domaine, wicket est plus complet que stripes mais ces deux framework sont vraiment proche dans l’esprit

Je cherchais comment personnaliser les messages de validation. Par exemple remplacer :

“le champ ‘dob’ est obligatoire”

Par :

“Veuillez saisir la date de naissance !”

C’était en effet bien tout prévu dans le framework, et de manière plutôt élégante et flexible.
Mais : mis 2h à trouver ce qu’il était possible de faire grace à la lecture du source, déduction de javadoc mal formulé, et des extraits de documents publiés par des utilisateurs sur leurs blogs.

Voilà qui fait râler…

Enfin j’avoue je répond a ce qui est dit ici sans avoir eu le courage ou la curiosité d’aller lire l’article original, honte a moi.

@Bastoune
+1 sur le coup de la doc dépassée … maintenant je ne trouve pas cela génant si l’on comprend ce que l’on fait et si l’on est pas feignant on s’en sort

Et puis une Quickstart il en existe un super : noocodecommit :p

@Nico
“bistoufly” c’est le code spaghetti c’est ca ? … c’est pas justement le genre de trucs qu’on cherche a banir dans toutes les archis web par le principe MVC notamment ? megaLol … Wicket complique la production de code de m&#@e

Oui, la liste de diffusion est active, mais nous parlions de documentation ! Regardez par exemple chez Yahoo pour la YUI : vous avez de la documentation à foison ET à jour, ET une communauté très active fédérée via un blog et un groupe Yahoo officiels.

D’ailleurs, tout a fait d’accord avec Frédéric Daoud sur l’importance qu’a la communauté et le rôle que l’équipe de développement doit jouer…

Tous ceux qui avaient quelque chose de négatif à dire à propos de Tapestry étaient immédiatement virés de bord avec des “il n’a rien compris” ou alors “pourquoi diable voudrait-on faire ça?”

Je me souviens aussi d’un post de HLS (l’auteur de Tapestry) qui critiquait très aggressivement Wicket, en disant avec arrogance que Wicket n’en était rendu qu’à ce qu’était Tapestry 0.0.1.

Maintenant que Wicket a gagné beaucoup de terrain, voilà que ce sont tous les Wicket fanboys qui virent toute critique avec des “il n’a rien compris” et “personne n’a besoin de faire tel feature.”

Je trouve que Dan a tenté de son mieux de faire valoir ses points, avec des explications détaillées et précises. Au lieu de l’écouter et tenter de l’aider, des gens aggressifs comme Igor lancent des “you clearly do not understand OO.”

Stripes gagne beaucoup de terrain ces jours-ci et la communauté est très accueillante et prète à aider les nouveaux. Je ne peux qu’espérer quece virage vers l’arrogance sera évité.

J’ai remarqué que Eelco s’est beaucoup calmé en termes d’aggressivité et d’attaques personnelles gratuites. Il répond plutôt avec diplomatie et tact, ce qui engendre des discussions techniques beaucoup plus intéressantes, au lieu de flames wars de geeks qui veulent montrer que la leur est plus grosse que la tienne.

Il n’est pas trop tard. Wicket est certainement un excellent framework. Il a ses forces et ses faiblesses. Rendez-vous compte que ce n’est pas un marteau en or dans un monde remplis de clous. Gardez l’esprit ouvert, l’image de votre communauté est tout aussi importante que les avantages techniques de votre framework.

Cheers,
Freddy

Je commence immédiatement par préciser que je rédige ce commentaire avec très présent à l’esprit que je ne suis qu’un très récent développeur objet : j’ai commencé sur un projet Java utilisant Wicket il y a moins de 1 an ! Mais par contre, au cours de 12 années d’expérience de développement d’applications Web, j’ai pu utiliser de nombreuses technologies et produits (cgi, asp, php, smarty, adaptations de cms et produits de ecommerce).

A lire l’article dont il est question ici, j’ai regretté qu’il manque de fond et surtout il aurait sans doute nécessité une réflexion un peu plus poussée. Je n’aurai cependant pas la prétention d’apporter tous les compléments ici, mais quelques points m’ont interpelés et je souhaitais en faire part dans la discussion.

- Documentation : il me parait tout à fait indéniable que Wicket a de très lourds manques de ce côté là ! Même si en effet il existe des choses, il faut souvent aller beaucoup fouiller pour des choses simples ! Et on tombe bien souvent sur de la documentation rédigée par un utilisateur, pas complète et obsolète… et ce sur le wiki officiel même ! Au final les sources principales d’information sont le source même et la mailing list.
Le framework avance vite et les ressources sont sans doute limitées, on peut le comprendre. Mais le manque de documentation officielle et structurée est criant, c’est absolument indéniable.

- Je suis assez mal à l’aise avec le sentiment que j’ai eu de prime abord et dont je n’arrive pas à me détacher : en utilisant Wicket on a l’impression que le dev Java fait tout, en oubliant complètement les intégrateurs HTML, dev front-end, admin, etc.
L’argument “Wicket probably decreased my template code by 4x but increased my Java code by 4x” me parait vraiment un point important. J’ai l’impression tenace que l’on arrive à tout faire en Java, et ce n’est vraiment pas bon pour la vie de l’application : chacun a son rôle et son domaine d’intervention, et le développeur Java ne devrait pas avoir à se préoccuper de CSS, cache, …
Maintenant que ça soit de la faute des développeurs utilisant Wicket ou que ça soit le framework qui y pousse, c’est à voir…

- Facile de mettre de l’Ajax de partout… Et de produire un site inutilisable ! “Don’t break the web”…

- Coder les traitements sur onSubmit et les actions Ajax directement en Java est très agréable ! Mais ça induit un peu de lourdeur pour l’intégration de choses front end que le développeur Java doit conserver des maquettes statiques… (cas récent : ajouter une lightbox d’attente après change d’une DtopDdownChoices)

- On a le moyen d’intégrer des datepicker directement pas exemple, et on lit très clairement sur la mailing list que les dev ne veulent pas que Wicket devienne une biblioth_que de widgets… La position là-dessus est à mon sens assez bancale.

Aussi, au jour le jour, le sentiment que Wicket est jeune :

- la gestion des url… l’argument revient et revient…

- surcharge des css : pas toujours évident

- quelque chose qui m’a scié : pour gérer convenablement des menus de navigation en ul/li il faut bricoler à la main !!!!

- génération de JS dynamique : côté bricolo encore

- séparation du code Java, des fichiers markup et des ressources : mériterait plus de flexibilité

Bref, pour l’instant (et je répète que j’ai bien conscience que mon expérience Java comme Wicket nécessite plus de temps pour être très pertinente) je trouve Wicket difficile et long à apprendre, souvent lourd pour du “quotidien”.
Si je compare avec des solutions de séparation templates / code que j’ai pu expérimenter il y a quelques années, Wicket me parait bien trop lourd et pas assez clair dans les séparations.

Moi qui ne connait pas grand chose dans la “programmation client léger” (pour être générique), je pense que Wicket est trés accessible. Bon, mais j’ai aussi (je crois) de bonnes connaissances en POO et je crois que sans ça, ça serait loin d’être évident.

En même temps, ce serait aussi stupide que de connaître unique que le C et de se lancer dans un gros projet en C++… :sauteunravin: