Discussion :

[ymajoros]

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é.
++

Bien d'accord, j'avais envie de répondre mais ça m'embêtait de le faire dans ce sujet.

[loic38_01]

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

C'est clair... en fait ce n'est pas forcément dans mes objectifs en tant que tel mais parfois je me dis que les choses seraient plus simples ainsi...

avec plaisir, mais une autre fois.

si tu as le temps de nous expliquer ça, n'hésite pas

[joseph_p]

si tu as le temps de nous expliquer ça, n'hésite pas

Fait : Intégration entre Wicket et Hibernate : une solution pour travailler en mode attaché

++

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

j'ai du mal à suivre là : je dis en substance que j'ai utilisé/benchmarké de nombreux frameworks web avant de m'arrêter, depuis quelques temps déjà, sur wicket, et que ceci dit je continue ma veille sur le domaine. Aussi, cela conforte quelle idée au juste, celle du bricolage ?

En effet, connaitre les outils existants et savoir pourquoi on en choisit un plutôt que l'autre, en fonction de l'usage qu'on en attend, relève à mon sens d'une démarche raisonnée et raisonnable, loin de toute mode, coup de tête ou comportement digne de moutons de Panurge.

Pour ce qui est des performances, en terme de runtime, peter thomas a fait une comparaison assez poussée sur le sujet, je vous laisse la découvrir.

Si on parle de la robustesse et rapidité du développement, je crois que les atouts mis en avant plus haut devraient déjà donner une bonne idée des avantages de wicket, surtout qu'ils ne sont pas exhaustifs (l'internationalisation vient de me revenir en tête récemment, ainsi que le soin mis par l'équipe wicket pour adapter wicket à ses besoins, tout en hook et autres settings).

Évidemment, dur de "prouver" la chose, à chacun de se faire son avis en fonction de ses besoins, expériences et inclinaisons, mais pour cela il faut se donner la peine de réellement essayer et de vouloir en tirer le meilleur.

Et au final, nous pouvons tout à fait être en désaccord, la terre ne s'arrêtera pas de tourner pour autant, loin de là

[loic38_01]

Fait : Intégration entre Wicket et Hibernate : une solution pour travailler en mode attaché

++

Super, merci beaucoup!!

[Jimmy_]

Quelques nouvelles sur mon projet,

Wicket a passé une première étape de validation auprès des architectes qui sont maintenant très amicaux avec l'open source. (Les acheteurs aussi vu le prix de certains frameworks commerciaux).
Le but est quand même d'aller consulter un progiciel déjà très cher via son API Java et de réaliser une interface riche de visualisation à moindre coup.
Et Wicket a fait mouche, il reste un bémol, certains chefs de projet lui reproche sa philosophie anti-javascript. Ce n'est pas que l'on ne peut pas en faire, mais la validation de surface coté serveur n'est pas leur tasse de thé. Il me reste donc à démontrer qu'il est possible de faire des validations de surface javascript de manière simple.

[Ricky81]

Il me reste donc à démontrer qu'il est possible de faire des validations de surface javascript de manière simple.

Regardes du côté de Wicket Stuff l'intégration de Yav

Tu as également un billet de Zenika sur le sujet.

[joseph_p]

Regardes du côté de Wicket Stuff l'intégration de Yav

Tu as également un billet de Zenika sur le sujet.

tu as été plus rapide que moi, ouarf

ça me fait penser que je lirai bien ton avis sur les limites de wicket

concernant la demande initiale, quelles sont les motivations des dits architectes pour pousser la validation côté client ? Qui sait, cela peut aider à apporter d'autres éléments de réponses.

[Jimmy_]

concernant la demande initiale, quelles sont les motivations des dits architectes pour pousser la validation côté client ? Qui sait, cela peut aider à apporter d'autres éléments de réponses.

C'est l'habituelle opposition de la charge serveur et réseau si pour une erreur de saisie basique on fait un appel serveur. J'ai pourtant prouvé qu'avec Ajax le flux est faible, les vieux poncifs sont encore présent.

[joseph_p]

C'est l'habituelle opposition de la charge serveur et réseau si pour une erreur de saisie basique on fait un appel serveur. J'ai pourtant prouvé qu'avec Ajax le flux est faible, les vieux poncifs sont encore présent.

sur le fond, ils n'ont pas entièrement tort. L'argument peut difficilement être contré AMHA. Bref, faut espérer que Yav fasse l'affaire.

[joseph_p]

en revenant sur le sujet initial du topic, j'ai récemment blogué sur le thème des tags libs et autres scriptlets, qui me font vraiment, au final, l'impression d'une fausse bonne idée. Plus par là : Pourquoi cet intérêt pour les scriptlets et autres taglibs ?
++

[el muchacho]

ymajoros, tes arguments ne tiennent pas la route. Si on te suit, on devrait continuer à faire du Struts 1 ou des JSP à la main parce que c'est encore ce qui se fait le plus couramment, si on se base sur le nombre de posts rien que dans ce forum. Choisir un standard parce que c'est un standard, c'est simplement avouer qu'on est incapable d'en évaluer les mérites et les inconvénients.
C'est malheureusement le cas de nombre d'architectes qui ont choisi les EJB 1 ou 2, ou JSF 1. Ce n'est pas à cause des mérites respectifs de ces frameworks, mais bien parce qu'on a eu affaire à des gens qui n'avaient pas la compétence pour évaluer l'impact de ces frameworks sur les développements mais les ont quand même choisis pour se couvrir en cas d'échec.
On sait depuis longtemp que tous les standards ne sont pas bons, et Sun en a pondus quelques-uns qui ont eu le mérite d'exister mais se sont révélés bien médiocres à l'usage. Ce qui a permis l'existence d'une solution alternative nommée Spring que tout le monde considère comme supérieure aux EJB2.
Je ne dis pas qu'il faut jeter tous les standards, mais il faut savoir les évaluer comme tout le reste et les écarter s'ils ne procurent pas un avantage compétitif. Tu cites JPA comme standard. Il se trouve que la première version était mauvaise, et que la version actuelle est largement inspirée d'Hibernate (et pour cause, les auteurs d'Hibernate ont participé à son élaboration). Comme quoi...

[moez123]

J'ai utilisé wicket dans pas mal des projets et j'ai remarqué les avantages suivantes :
- Documentation riche
- forum (users@wicket.apache.org) tjrs actif
- pas de fichiers de configurations (comme struts-config...)
- un simple mapping java/properties/html sans config (juste le meme nom)
- est un framework d'apache
- plugin netbeans
- facile à intégrer avec spring, jpa, ejb3...
....

Et pour cela, j'ai vraiment adoré ce framework et meme j'ai commencé à ecrire des articles la dessus:

[Eric Taix]

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

C'est assez vieux comme thread, mais oui prenez quelques heures pour tester Vaadin. Simple, efficace, personnalisable, bref c'est mon framework préféré du moment.

Comme retour d'expérience voici un lien d'une petite application que j'ai faite l'année dernière en full Vaadin: http://dot-art.cloudfoundry.com/

Aucune difficulté bien que que certaines fonctionnalités sortaient du cadre de Vaadin. Mais j'ai réussi dans difficulté à trouver la bonne façon de faire. A noter d'ailleurs que IT Mill édite un bouquin (gratuit) sur Vaadin et qui est extrêmement bien faire. J'avais essayé de faire la même application avec PlayFramework + JQueryUI et j'ai arrêté devant la difficulté (relative) où cela m'emmener (ancienne application visible sous http://dot-art.appspot.com/ : cette app sur GoogleApps ne fonctionne pas, c'est un proto et long au chargement car Google Apps décharge les applications quand elles ne sont pas utilisées...)