Discussion :

[stouf()]

Bonjour à tous

J'ai du mal à choisir un framework et j'ai cru voir dans certain post que wicket était vraiment bien et facile a mettre en place

J'aurai alors quelques questions pour vous

J'ai lu que wicket était bien pour ceux qui programmais plutot coté applicatif avant ??

peut-on faire tout un site avec wicket et jpa réunit ? et un design correct (implémentation de CSS ?) ??

Quel différence avec GWT ??

Auriez-vous quelques liens pour moi apprendre wicket pas juste que les bases mais ce que le framework peu apporter


Merci bcp

Stouf()

[djo.mos]

Salut,

J'ai lu que wicket était bien pour ceux qui programmais plutot coté applicatif avant ??

Je vois pas pourquoi ... ou plutôt que serait la différence parapport aux autres frameworks web dans la mesure où Wicket s'occupe de la partie frontale.

peut-on faire tout un site avec wicket et jpa réunit ? et un design correct (implémentation de CSS ?) ??

Bah oui évidemment à moins que j'ai mal compris la question.

Quel différence avec GWT ??

GWT s'exécute dans le client (avec possiblité de faire du remoting pour invoquer un traitement sur le serveur et/ou en récupérer des données).

Dans le cas de Wicket, la page est générée dans le serveur et affiché chez le client. avec le workflow usuel de wicket (Link, Form, etc.), le traitement se fait côté serveur (mais rien ne t'empêche d'inclure du javascript et donc côté client).

Auriez-vous quelques liens pour moi apprendre wicket pas juste que les bases mais ce que le framework peu apporter

C'est comme un des points qu'on retient contre Wicket. La doc manque pas, y'a son Wiki http://cwiki.apache.org/WICKET/ , les mailing lists archivés sur Nabble par exemple http://www.nabble.com/Wicket---User-f25133.html , et de plus en plus de livres (Wicket in Action par exemple). Mais pas de documentation centrale.

[stouf()]

Salut djo.mos,

Merci pour ta réponse, j'en aurai encore une est-ce que l'ajax est intégré d'office genre GWT ? ou il faut le programmer soi même ?

Merci d'avance
stouf()

[djo.mos]

Oui, wicket gère nativement l'ajax, le tout sans avoit à coder une seule ligne en Javascript.

[stouf()]

il a l'air très intéressant mais quel est son avantage par rapport a JSF + richfaces ?

car ils produisent le même résultat au final et JSF fait partie de la norme J2EE

Edit: il n'a pas l'air de posséder non bcp de composant genre progressBar ou autre ... (p-e est-ce en évolution ?)

[djo.mos]

il a l'air très intéressant mais quel est son avantage par rapport a JSF + richfaces ?

car ils produisent le même résultat au final et JSF fait partie de la norme J2EE

Edit: il n'a pas l'air de posséder non bcp de composant genre progressBar ou autre ... (p-e est-ce en évolution ?)

Bonne question.
La réponse porte surtout sur le style. JSF a choisi le chemin full managé + full déclaratif, Wicket a pris l'autre voie.

Dans le cas de JSF :
- Tu décris tes pages en utilisant des composants JSF via un langage à base de markup (mais qui n'est pas le html). Tu peux les attacher à des composants en Java, mais ces classes Java sont d'une complexité et d'une mocheté qu'il en sont presque inutilisables
Ca te permet de faire abstraction de ce qu'il y'a en dessous (genre faire le rendu d'une même page vers html, wml, pdf, etc.).
De plus, ça te permet de coder rapidement des interfaces complexes en tirant profit de puissants compoosants disponibles (Richfaces, Icefaces).
Ca marche bien ce modèle, jusqu'au jour où t'as besoin de modifier un tit truc que les concepteurs de composants n'ont pas pensé le rendre personnalisable. Là, ça fait très mal
- Le lien entre les composants et le model se fait via EL (obligé, vu que la partie composants c'est du déclaratif). EL n'est pas très puissant et es tputôt assez limité.
- JSF gère tout, comme par exemple la création des managed beans.


Bien que Wicket est lui aussi à base de composants, il s'y prend autrement :
- Tu décris tes pages en HTML et tu lies des tags HTML à des composants en Java. A l'inverse de JSF, ces classes Java sont plutôt simples et propres, vu qu'ils ont été conçues dès le départ pour être utilisé par le développeur. Ca te donne donc un contrôle quasi-total sur le rendu de tes pages. Par contre, c'est bas niveau, et donc, plus de composants magiques à la JSF qui te gènère une table super zolie avec zebra-striping et pagination Ajax et tout
- Tout ou presque se fait en Java. Ca te donne infinimeent plus de puissance et contrôle que l'approche de JSF. Un exempel tout bête qu ime vient à l'esprit est Ajax. Avec Richfaces (ou ajax4jsf plutôt), l'ajax est hyper simple, mais tu dois spécifier dans le markup quel composants redessiner après la requête. Avec Wicket, tu fais ça mais en java. Tu peux donc dire redessiner un composant X si le résultat est tel ou Y sinon, ce que tu ne peux pas faire en JSF.
- Wicket est plus matur que JSF. Ca peut paraître bizarre, mais c'est le cas. wicket gère par exemple les ressources, qui seront inclus dans JSF 2. L'internationalisation est aussi plus solide et simple avec Wicket, etc. etc.

Bref, j'ai essayé de résumer et de te donner une vue d'ensemble de mes opinions sur la chose.
Mais tu peux te faire ta propre idée, il se peut que JSF te plaise plus ou qu'il te semble plus adapté à ton besoin.

[stouf()]

un grand merci pour ta réponse!!
Je suis convaincu et je vais me mettre à Wicket, je préfère le codage version java que tout déposer sur la page

Encore merci djo.mos!!

[JauB]

Je suis convaincu

Déjà?

[Nithril]

A mon sens, le principal inconvenient de Wicket est le manque de richesse et de maturité des composants surtout quand on le compare avec Richfaces.

L'autre inconvenient, mais plus subjectif, est que Wicket est un framework jeune soutenu par Apache. Alors que JSF c'est Sun, JBoss, Spring, Oracle... Ca donne un coté pérenne rassurant.

Par contre je ne suis pas d'accord djo.mos quand tu dis que Wicket est bas niveau. Je dirais qu'au contraire Wicket est d'un niveau plus haut que JSF et qu'il pèche surtout par des composants fonctionnellements moins aboutis.

Wicket gere nativement les onglets. Pas besoin de se prendre la tete a créer une liste et a la gerer a la mano, meme chose pour les modals panels, les modeles, le mix reRender coté page et le addComponentToAjaxRender coté Java de JSF, l'arbre des composants JSF peux accessible qui contient tout et n'importe quoi...

Wicket c'est une bombe.

[djo.mos]

Salut

A mon sens, le principal inconvenient de Wicket est le manque de richesse et de maturité des composants surtout quand on le compare avec Richfaces.

Oui, on entend souvent ce point là comme inconvénient de Wicket.
Mais faut savoir que Wicket, le framework c'est pas du RIA. il essai de fournir une fondation solide qu'on peut batir des composants dessus. Qui plus est, Wicket de base fournit des composants beaucoup plus puissants/riches que JSF de base : tree, tabs, treeTable, etc.
De plus, le problème avec les composants haut niveau est justement qu'ils sont haut niveau : ils ne peuvent pas te donner la main pour configurer tout, et tôt ou tard tu tomberas sur un point que tu veux mais ne peux pas configurer.
Je suis donc d'avis que de tels composants ne doivent pas faire partie de la distrib de base d'un framework, mais plutôt dans des projets séparés, comme celui-là par exemple.

Mais c'est vrai qu'il manque à Wicket un jeu de composants (externe) de la taille/qualité de Richfaces par exemple.

L'autre inconvenient, mais plus subjectif, est que Wicket est un framework jeune soutenu par Apache. Alors que JSF c'est Sun, JBoss, Spring, Oracle... Ca donne un coté pérenne rassurant.

Mouais ... je veux pas lancer un troll mais faut savoir qu'un standard n'implique pas forcément mieux conçu ... d'ailleurs les standards qui ont vraiment décollé (je cite JPA par exemple) sont inspirés de projets OSS d'Apache/JBoss/Codehaus/etc.

Par contre je ne suis pas d'accord djo.mos quand tu dis que Wicket est bas niveau. Je dirais qu'au contraire Wicket est d'un niveau plus haut que JSF et qu'il pèche surtout par des composants fonctionnellements moins aboutis.

Tout dépend de la définition du bas niveau : moi quand je dis bas niveau c'est parceque avec Wicket je manipule directement les éléments/attributs HTML, et non pas d'autres abstractions au dessus (ValueBinding et co).

Wicket gere nativement les onglets. Pas besoin de se prendre la tete a créer une liste et a la gerer a la mano, meme chose pour les modals panels, les modeles, le mix reRender coté page et le addComponentToAjaxRender coté Java de JSF, l'arbre des composants JSF peux accessible qui contient tout et n'importe quoi...

oui, mais ça n'empeĉhe que l'approche de Wicket est plsu bas niveau que celle de JSF amha.

Wicket c'est une bombe.

Oui mais pour relativiser les choses, avec Wicket, faut faire très gaffe au 'state monster' ... il est beacoup trop facile de sérialiser accidentellement tout un graphe d'objets dans la session

[joseph_p]

Allez, j'y mets mon grain de sel

Je vais commencer par des questions, hein

vous utilisez wicket en entreprise ou pas ? Avez vous une expérience intensive avec la bête ?

pour ma part, après avoir bidouillé avec pendant plus de 2ans, voici 3 mois que je l'utilise en milieu professionnel avec un responsable technique de feu de dieu.

mes impressions sont les suivantes : wicket est orienté html à fond à fond, tout ce qui est possible avec html/css l'est avec wicket, et souvent de façon simple et puissante. La relative absence de composants fonctionnels élaborés vient sans doute de là : il est très simple de se faire ses propres composants aussi complexes soient ils.

A propos de composants, c'est le seul framework web, à ma connaissance, qui propose un tel niveau de réutilisation et de capitalisation.

côté points faibles, à mon sens, j'en vois deux : la notion de modèle n'est pas toujours évidente et a quelques coins sombres qui peuvent mettre du temps à s'éclairer. A propos, savez vous comment wicket fait pour prendre en compte les modèles, et notamment assurer leur rechargement le cas échéant ?

Ceci dit, la logique derrière, cette fameuse indirection unique à wicket, a vraiment du bon et explicite vraiment les choses vis à vis du comportement à adopter par l'application pour accéder aux données.

Et puis... mon mighty tech leader a mis au point un "EntityModel" qui s'occupe d'attacher/réattacher les entités au besoin (lors de changement de thread par exemple), tout en conservant aussi les entités non persistantes, qui permet de faire des choses vraiment de folie sans se prendre la tête. Que du bonheur, vraiment.

Le 2eme point concerne l'ajax. Certes, c'est facile de faire de l'ajax "à la wicket", cad avec tout en callback serveur, mais j'ai, jusqu'ici, l'impression que non seulement ça complexifie sacrément les pages html mais que, surtout, c'est pas toujours tip top.

En fait, j'ai régulièrement des "channel busy - postponning" sur des pages complexes (plusieurs fenêtres modales, des AjaxLink en veux tu en voila et ce genre de choses). L'appli devant aller en prod prochainement, je suis curieux/anxieux de voir ce que cela donnera de ce côté là.

D'ailleurs, je ne sais pas bien si c'est moi qui fait mal ou wicket qui assure moyennement (les connaissant, j'avoue un doute sur cette dernière hypothèse ). Si vous avez des retours d'XP, conseils sur ce point, je suis plus que preneur

Au final, je dirai que pour faire du web de façon rapide, propre et robuste (en évitant l'excès d'Ajax AMHA), tout en restant proche des capacités réelles du web, wicket est vraiment au top.

[Nithril]

Salut
Tout dépend de la définition du bas niveau : moi quand je dis bas niveau c'est parceque avec Wicket je manipule directement les éléments/attributs HTML, et non pas d'autres abstractions au dessus (ValueBinding et co).

Oui, car pour moi faire du binding, c'est faire du bas niveau coté tuyauterie Java

[stouf()]

à tout hasard existe-il une liste de tout les composants existants dans wicket ?

[joseph_p]

tu peux regarder par là :
http://wicketstuff.org/wicket13/compref/
http://wicket.apache.org/docs/wicket...et-extensions/
=> wicket extensions est maintenu par apache et l'équipe wicket

http://wicketstuff.org/confluence/display/STUFFWEB/Home
=> éléments non maintenus par apache. Tout le monde peut y déposer ses petits composants (grosso modo)

EDIT : ah oui, y a aussi ça :
http://www.wicket-library.com/wicket-examples/

have fun

[stouf()]

thanks !!!

Sur mes premières petites expérience de ce framework j'en ressors conquis !! je vais passer quelque chose de plus important.

Merci à tous pour toutes vos précisions

[stouf()]

je vais rajouter une question
Connaissez-vous un endroit ou je pourrais downloader la javadoc de wicket et wicket-extension ?? car je boss bcp dans le train et donc pas accès à internet

[djo.mos]

Salut,
Je ne me rappèle plus depuis quelle version (la 1.4.* peut être), mais la version archivée téléchargeable de Wicket inclut désormais les JavaDocs.