Salut
J'ai récemment eu ce PM de Pill_S :
Bonjour,
dans une discussion J2EE, nous en sommes venus à aborder le sujet de Wicket, et votre nom a été cité par sinok.
Vous êtes à ma connaissance la seule personne du forum à avoir une expérience de ce framework. J'envisage moi-même de l'introduire dans mon environnement professionnel, et j'aimerais connaitre vos avis sur le sujet. Qu'apporte Wicket par rapport à JSF ou Struts (ou d'autres)? Avez-vous tenté de l'intégrer dans Spring, et si oui, cette intégration s'est-elle faite sans douleur? Est-ce que Wicket est suffisamment abouti pour défendre sa place dans un projet professionnel?
Merci d'avance de vos réponse. N'hésitez pas à poster à la suite du topic plutôt que par MP si vous préférez la rendre publique.
Alors, en quelques mots :
- Qu'apporte Wicket par rapport à JSF ou Struts (ou d'autres)?
Ce que j'apprécie beaucoup est le "no XML hell", la simplicité de mise en oeuvre et la possibilité d'aisément faire des pages Ajax complexes, sans être expert Javascript ou même du framework Wicket en lui même. Parmi les autres avantages "comparatifs", je mettrai également une très grande simplicité de créations de composants réutilisables (que ce soit avec l'html correspondant ou pas notamment), un mappage des données bien foutu, une vraie séparation html/code (tout est clair du coup, et même à la génération du code html, c'est vraiment lisible) et un codage très "Java" concis et propre dans sa mise en oeuvre. A noter également que les besoins "de base", comme la validation des saisies par exemple, sont très bien intégrés, ce qui est un vrai plaisir pour le développeur.
Ultime avantage : rarement vu une mailing list aussi réactive et "pro" : les 3/4 des développeurs du framework sont dessus en permanence, permettant vraiment une aide top et quasi temps réelle. Impressionnant !
Seul hic, ou du moins limitation à prendre en compte, Wicket fonctionne vite avec une notion de session liée à l'utilisateur, ce qui implique bien sûr des sessions expirées. Je dirai que là tout dépend du contexte : si l'utilisateur doit se logger, ça ne gêne aucunement, mais si les pages doivent être accessibles tout le temps pour tout le monde, quelque "pages expirées" de temps à autre sont à attendre je pense (quoique il soit possible de faire des "stateless page" mais je ne me suis pas trop penché sur la question).
- Avez-vous tenté de l'intégrer dans Spring, et si oui, cette intégration s'est-elle faite sans douleur?
Je l'ai fait, et c'est sans douleur. En fait, il faut savoir que Wicket, à la différence de Spring (ou Tapestry), n'est pas un framework "managé" : c'est le développeur qui créé des "new Page()" et ainsi de suite. Du coup de prime abord les 2 frameworks ont un delta. Toutefois, via une annotation (@SpringBean de mémoire), on peut très aisément injecter des objets managés par Spring. Perso j'avais fait le test avec Spring et Hibernate, je n'ai eu aucun soucis, surtout que wicket a un modèle de données qui se base sur un id d'objet pour aller chercher les infos quand besoin automatiquement. Bref, ça a été bien pensé et mis en oeuvre. J'avoue par contre avoir zappé Spring au final en faveur d'hibernate seul, mais c'est parce qu'il s'agit d'un petit projet perso et que je suis fainéant
-Est-ce que Wicket est suffisamment abouti pour défendre sa place dans un projet professionnel?
Personnellement je pense que oui, et je dirai même plus : il a un grand nombre d'atouts !
De par mon job passé et ma curiosité, j'ai vu pas mal de frameworks web, et souvent ça finissait (que ce soit du php, .Net ou Java) avec plein de code dans l'équivalent de la page html, avec du javascript ayant de jolies variables nommées a, b, c et d et bien sûr du code métier. Un sacré bordel en somme. Là, tout est en Java dans des classes Java : tous les outils sont toujours présents, ce qui facilite beaucoup la vie, et le tout dans un seul langage.
De plus, entre cela, le découpage aisé par composants et une logique proche du développeur Web (on créé une page à laquelle on associe un template html et des composants), je pense que du Wicket doit vraiment être agréable à maintenir.
Pour démarrer, je conseillerai de travailler directement à partir du source Wicket (histoire d'avoir tout sous les yeux), avec les exemples fournis et conséquent sur la même machine et en ayant parcouru le wiki voir acheté Pro Wicket. Wicket in Action devrait bientôt arriver, écrit par des développeurs du framework (un chapitre est dispo gratuitement sur le site de l'éditeur) et il a l'air des plus prometteurs. Perso je n'ai que moyennement aimé l'écriture de Pro Wicket, mais il présente déjà le nécessaire et constitue une bonne base.
Bon, pour finir et ne pas induire en erreur, mon petit projet perso n'avance pas bien vite du coup je ne peux pas faire un "vrai" retour d'expérience. Par contre, j'ai tout de suite commencé par les aspects web les plus compliqués (une carte dynamique via Ajax) et cela a été d'une simplicité déconcertante. Je me suis vraiment demandé pourquoi j'avais galéré avec Tapestry, struts, php et autres Grails avant
J'avoue par contre que la mailing list m'a bien aidé
lol
Au delà, Wicket semble déjà bien utilisé dans des entreprises, cf le wiki et les annonces sur la ML.
En cas d'autre(s) question(s), ne pas hésiter !
++
ZedroS/Joseph
0 |
0 |
Envoyé par Pill_S
