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.