Discussion :

[Pill_S]

Bonjour à tous,

je me penche actuellement sur les applications web en java.

J'ai beaucoup lu sur tous les grands frameworks actuel, Struts, Spring, JSF, etc, mais au final je ne me rend pas bien compte des grandes forces de chacun. Ok, Spring est une sorte de container MVC qui s'adapte à tout plein de combinaisons différentes, il a donc un statut particulier par rapport à Struts et JSF, mais son gestionnaire de Vue (SpringMVC/JstlView) est-il à la hauteur de Struts?

Quels sont les raisons qui devraient me faire utiliser plutôt l'un ou l'autre? Qu'utilisez-vous dans votre vie professionnelle? Et pourquoi?

Merci d'avance de m'aider à y voir plus clair (c'est un peu la jungle J2EE!)

[sinok]

A l'heure actuelle j'irais fouiner plutôt du coté de Wicket et Tapestry en ce qui concerne la couche MVC de présentation. Ce sont deux frameworks orientés composants, c'est à dire ressemblant pas mal à du dev Swing classique, et surtout évitant une suraccumulation de logique au niveau des JSP (en fait il n'y a même plus de JSP mais quasiment que de l'HTML avec des attributs spécifiques). Toutefois ils ne sont pas aussi "lourds" et complexes que JSF qui par moments tient du bazooka pour tuer une mouche (tout dépend de ce que l'on cherche à mettre en place).
Struts est en fin de vie pour la version 1, la version 2 étant complètement différente, et à ce jour je n'ai pas vraiment eu l'occasion d'en entendre.
ENfin pour dire wue Wicket et Tapestry sont des frameworks récents dans leurs dernières versions, possèdent une bonne intégartion au niveau AJAX (au moins pour Wicket mais

En ce qui concerne Spring c'est une autre histoire.
Ce framework dépasse largement le cadre su MVC et régit l'intégralité du cycle de vie de ton appli (de la partie connexion au SGBD jusqu'au niveau de la pres). Les frameworks précités peuvent tous s'intégrer dans Spring de fait.

Enfin je n'ais pas vraiment d'expérience avec ces frameworks, mais je relate plutôt là ce que j'ai pu lire à gauche à droite dans la blogosphére java

[gronono]

Sur le projet sur lequel je travaille, on utilise GWT.
C'est quasiment comme développez un application SWT. Ensuite le compilateur génère du HTML/Javascript pour interroger le serveur.

C'est vraiment pratique d'utilisation.

A+
Gronono

[fisico]

JSF parce que c'est une spécification.

[Pill_S]

AJAX est en effet un aspect indispensable à nos futurs projets (Web2.0 oblige...)

Concernant Wicket, est-ce que quelqu'un l'a déjà utilisé? Il me semble être un peu jeune actuellement (ce n'est pas forcément mal) mais c'est plus difficile de le défendre face à un chef de projet sceptique...

Et surtout, peut-il s'intégrer dans Spring sans trop de problème?

JSF parce que c'est une spécification.

Ce n'est pas un argument... EJB a aussi une spécification, mais ne fait pas le poids face a hibernate...

[Wyfrel]

Est ce qu'il existe un article qui compare les différents framework ??

Où est ce qu'il serait pas possible de rassembler l'expérence de cahncun sur ce forum pour en faire un ?? (peut être en commencant par faire uen liste des framework les plus utilisés ...)

Parce que il existe tellement de framework différent qu'il est difficile de comprendre les avantages/ inconvénients de chacuns.

[sinok]

Tu as zedros qui a déjà bossé dessus, il y avait un retour sur son blog:

http://blog.developpez.com/index.php...mit=Rechercher

De plus Wicket depuis juin dernier fait partie des top level projects apache, c'est à dire que la fondation apache a estimé qu'il avait maturé suffisemment longtemps pour être utilisé en prod. De plus ce projet a quand même un poil d'ancienneté (je me souviens d'un artcle de Gfx dans un Login d'il y a 3-4 ans)

De même ce framework a déjà fait l'objet de sessions à JavaOne donc possède un tant soit peu de légitimité.

[fisico]

AJAX est en effet un aspect indispensable à nos futurs projets (Web2.0 oblige...)

Concernant Wicket, est-ce que quelqu'un l'a déjà utilisé? Il me semble être un peu jeune actuellement (ce n'est pas forcément mal) mais c'est plus difficile de le défendre face à un chef de projet sceptique...

Et surtout, peut-il s'intégrer dans Spring sans trop de problème?


Ce n'est pas un argument... EJB a aussi une spécification, mais ne fait pas le poids face a hibernate...

Pour toi, le fait que JSF est une spécification, ce n'est pas un avantage?

[Pill_S]

Pour toi, le fait que JSF est une spécification, ce n'est pas un avantage?

Un avantage peut-être, mais en tout cas pas suffisant pour être décisif.

Avant tout, il me faut quelque chose de puissant, facile à implémenter et maintenir, et modélisé comme il faut (bonne séparation des couches).

Le reste, après, m'importe peu...

Wicket me semble donc assez adapté. Je vais continuer à me documenter sur plusieures options, je suis obligé de bien prévoir mon coup (à terme, nous allons mettre en place des structures identiques pour une grande variété de projets, et dans une équipe qui va fortement s'agrandir dans peu de temps).

[joseph_p]

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

[joseph_p]

Salut Pill_S

Je pense que tu prends un peu le problème à l'envers : de quoi as tu besoin en 1er lieu ?

Par exemple comment réponds tu aux questions suivantes :
- te faut il adhérer à des standards type JCP ?
- désires tu un environnement de dév très fourni et développé ?
- as tu besoin de "widget" standard pour faire du simple CRUD * ou auras tu des éléments bien plus spécifiques ?
- veux tu qu'un gros éditeur soit derrière la solution retenue ?
- veux tu rester dans une gamme, genre que du Java à la sauce IBM, JBoss ou que sais je ?
- veux tu une séparation claire entre html et reste du code ?
- désires tu des interfaces très très riches ou entièrement Ajax ou mixte ou ... ?
- dois tu t'intégrer dans une architecture existante ?
- le framework retenu sera utilisé par une petite ou grande équipe ? Quelles sont les connaissances de cette équipe ? Plutôt Javascript, html, php, Java, Flash ou ... ?
- l'aspect Open Source est il important/bloquant pour toi ou ton entreprise ?
- faut il que vous puissiez payer un support ? (C'est souvent un prérequis dans certaines boites, quelque soit la validité d'un tel argument)
- la rapidité de réalisation des pages web/sites est elle plus importante que leur customisation ?
- as tu besoin d'intégrer des pages web d'autres technos ?

En somme, détaille plus et on tentera de t'aider

Au demeurant, oui c'est clairement la jungle. Surtout que là on ne parle que des outils permettant de créer des pages webs, mais bien souvent le réel besoin relève plus d'une CMS évoluée, avec là encore une multitude d'acteurs sont présents.

A l'inverse ceci dit, en cherchant un peu, il y a vraiment moyen de trouver la chaussure parfaite. Pour ma part c'est le cas avec Wicket, pour les raisons exposées plus haut, mais tes besoins peuvent être différents.

Toujours à propos de cette diversité, on en voit là le côté "faiblesse" : que choisir ?

Mais en pratique c'est aussi une énorme force, surtout pour tout ce qui est open source (la grande majorité des cas) : pas de risque qu'un éditeur décide de pousser ses utilisateurs à passer à la version suivante, possibilité de voir le code source pour comprendre vraiment ce qu'il se passe (utile dans les cas tordus où le support manque, même chez de grands éditeurs). De plus, au final, il y aura toujours une solution à un problème.

En fait je crois qu'il faut un peu démystifier ces frameworks, ce ne sont que des boites à outils, et on peut combiner les outils ou faire ça à l'ancienne, au choix

* : Create Retrieve Update and Delete : acronymes désignant des applications qui sont très proches des données sans besoin d'interface complexe.

Allez, courage

++
Joseph

[Pill_S]

Bonjour,

Par exemple comment réponds tu aux questions suivantes :
- te faut il adhérer à des standards type JCP ?
- désires tu un environnement de dév très fourni et développé ?
- as tu besoin de "widget" standard pour faire du simple CRUD * ou auras tu des éléments bien plus spécifiques ?
- veux tu qu'un gros éditeur soit derrière la solution retenue ?
- veux tu rester dans une gamme, genre que du Java à la sauce IBM, JBoss ou que sais je ?
- veux tu une séparation claire entre html et reste du code ?
- désires tu des interfaces très très riches ou entièrement Ajax ou mixte ou ... ?
- dois tu t'intégrer dans une architecture existante ?
- le framework retenu sera utilisé par une petite ou grande équipe ? Quelles sont les connaissances de cette équipe ? Plutôt Javascript, html, php, Java, Flash ou ... ?
- l'aspect Open Source est il important/bloquant pour toi ou ton entreprise ?
- faut il que vous puissiez payer un support ? (C'est souvent un prérequis dans certaines boites, quelque soit la validité d'un tel argument)
- la rapidité de réalisation des pages web/sites est elle plus importante que leur customisation ?
- as tu besoin d'intégrer des pages web d'autres technos ?

Niveau standards, le seul à respecter est l'xHTML strict. L'IDE sera Eclipse, et je ne désire pas particulièrement de gros éditeurs derrière (même si ça aurait tendance à rassurer les autres dév.), niveau gamme je préférerais rester un max en java POJO. Ajax est indispensable afin de faire des trucs rapides et agréables, les composants utilisés seront simples (affichage de données tabulaires, composants type 'calendrier', formulaires de toute sorte, génération de documents pdf/excel, mais aussi quelques éléments Flash). L'architecture sera déterminée par nous. L'équipe est encore très petite (2 personnes) et mon collègue est surtout expérimenté en php (procédural), nous devrions nous agrandir en fonctions des besoins d'ici quelques mois. Perso, j'ai de solides connaissances de J2SE (swing, io, ...), mais je débarque dans J2EE. L'Open Source serait plutôt apprécié, mais est dispensable. Le support est inutile si la documentation est correcte. Et je met une priorité sur la beauté et la clarté du code (la m**** actuelle est impossible à maintenir et nous fait perdre des jours pour des modifications mineures, et évidemment il y a toujours des bugs qui apparaissent).

Je cherche plutôt un solide point de départ qui nous permette d'être très réactifs et de garantir une stabilité correcte, en découpant correctement l'appli (c'est d'ailleurs pour ça que je cheche également à utiliser Spring).

Vous l'aurez compris, notre structure n'est pas très "pro", mais j'ai l'intention de changer cela et de mettre en place quelque chose "qui tue"... Wicket me semble simple, c'est déjà quelque chose d'intéressant (la personne qui s'occupera des templates html n'est pas tout à fait hyper compétente, et il faut qu'il puisse comprendre en gros ce qu'il se passe).

Voili

[joseph_p]

Salut

Bon ben euh, comment dire, Wicket semble bien coller à tes besoins, notamment en termes de clarté et de beauté du code. Y a plus qu'à essayer j'dirai, histoire de te faire ta propre idée

A propos, voici un tuto que j'ai écris mais non encore publié :
http://zedros.developpez.com/tutoriels/java/wicket/ (j'attends la sortie de la 1.3, qui est en beta 4, et il faudrait que je le traduise, flemmard que je suis ).

Ultime "recommandation": il te faudra bien lire l'anglais (pratiquement aucune ressource en français, mais le changement ne dépend que de nous ) et pour commencer je te conseille de t'inspirer avec les exemples fournis. Et éventuellement, peut être pourrai je t'aider !

Ah oui, une dernière chose : Wicket est réputé être parfois un plus coûteux que la moyenne en terme de perf côté serveur. Il y deux réponses à cela :
- la 1er est de dire que, tout simplement, mettre quelques milliers d'euros (ou francs suisses ) dans un serveur est bien moins cher que de ralentir la productivité des développeurs
- la 2eme, plus "propre", est de dire que cela peut s'éviter en utilisant des "Detachable Models", cad des modèles où les données ne sont pas toutes tenues en session mais rechargées à partir d'un identifiant. Plus de détails là :
http://cwiki.apache.org/WICKET/worki...et-models.html

voili voilou

N'hésite pas à me solliciter au besoin

++
Joseph/ZedroS

[Pill_S]

Re-Bonjour, après avoir passé la première période de prise en main et réaliser mon premier formulaire, je dois dire que ce framework (Wicket) est vraiment super bien conçu! ça devient vraiment agréable de coder un site web. Auparavant, je trouvais ça plutôt fastidieux et répétitif, mais là c'est vraiment du nouveau. Ce qui me plait le plus, c'est de ne plus devoir gérer nous même les transactions http (on programme sans se préoccuper des rechargements de page ni des urls, exactement comme on le ferait en swing!) J'aurais juste une petite question. Je cherche à fournir des traductions du site, et à bien les séparer du reste de l'application (les traductions sont surtout utiles pour... les traducteurs) J'aimerais arriver à la structure suivante dans mon projet:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
/src
  /my/package/MyComponent.java
  /my/package/MyComponent.html
  /my/package/MyComponent.properties // valeurs par défaut
 
  /properties
    /malangue1
      MyComponent.properties // stocke "Bonjour Monsieur!"
    /malangue2 
      MyComponent.properties // stocke "Good morning Mister!"

... ou quelque chose de proche... Est-ce que quelqu'un pourrait me mettre sur la voie (je pense surtout à ZedroS)? Merci d'avance

[sinok]

Bah au pire tu fais comme sous swing, chaines externalisées dans un RessourceBundle et un fichier properties par langue (avec en suffixe _fr pour français, _us pour anglais US et ainsi de suite: trucmuche_fr.properties par exemple ) et tu switches selon la langue du navigateur de l'utilisateur, si ce n'est pas fait par défaut, je ne me souciens plus

[Pill_S]

Mon problème est surtout pour indiquer à Wicket qu'il ne doit pas prendre les fichiers du répertoire courant, mais ceux d'un autre ...

[djo.mos]

Bonjour.
C'est un peu tard vu que l'interssé a déjà basculé sur Wicket, mais j'ai voté pour JSF, non pas parceque c'est une spécification (les anciennes versions des EJBs sont un excellent contre-exemple), mais parceque je l'ai essayé, j'ai travaillé dessus et j'ai déjà réalisé un projet de taille respectable ladessus et j'entamme mon second.
En gros, voici les quelques points qui font que j'adore travailler sur JSF:

• Abstraction complète du HTTP et du HTML: comme évoqué précedemment pour Wicket, avec JSF on bosse pareil à Swing: on mets de sboutons et des liens et on les associe à des méthodes d'un POJO. L'encodage nécdessaire, le transport, etc. ne concerne pas le programmeur.
• Architecture super ouverte et extensible. Pour s'en convaincre, il suffit de jeter un petit coup d'oeil sur les différents jeu de composants ajaxifiés et tout batis la dessus.
• Malgré l'aspect XML Hell, la syntaxe de JSF est hautement déclarative et très différente de Struts par exemple. Par exemple, la construction des tables en JSF passe par les colonnes, et non pas un tag spécial d'itération + les tags HTML du row (tr) + les tags td.
• Les jeu de composants "pro" disponibles gratuitement (et/ou en opensource) comme RichFaces par exemple.
• La flexibilité: on intéragit avec des POJOS simples (pas d'ActionForm ou Action à hériter depuis, etc.), on navigue par des chaînes (au lieu d'ActionForwward dans Struts par exemple), etc.
• Un support de plus en plus grandissant par les ides (eclipse WTP 2, Exadel Studio, RedHat Developers Studio, myeclipse, etc.)
• Facelets. Euh ... oui, pour moi, facelets qui est une technologie de présentation spécifiquement crée pour JSF est une raison suffisante pour utiliser JSf ;-) Elle est tellement élégante comparé à Tiles par exemple (sans vouloir offencer personne)

Voilou.
Par contre, je crois que je devrais bien consacrer un peu de temps à Wicket pour le découvrir (j'y connais que dalle) parceque d'après ce qu'on raconte la dessus, il m'a l'air intéressant et surtout proche de l'esprit de JSF.

[cyrille37]

J'ai voté pour Tapestry. Et j'aime bien aussi Wicket et Echo (qui n'est pas dans la liste d'ailleurs).

Tapestry est très puissant, par contre il ne gagnera pas dans les sondages tant qu'il manquera des tutos ...

Heureusement Baptiste Meurant améliore sa visibilité :

Premier projet avec Tapestry5, Spring et Hibernate :
http://baptiste-meurant.developpez.c...ing-hibernate/

Intégration simple et élégante d'AJAX avec DWR :
http://baptiste-meurant.developpez.c...ing-hibernate/

Sécurisation d'une application Web avec Acegi Security:
http://baptiste-meurant.developpez.c...ing-hibernate/

Tiens, en passant, ces tutos ne sont pas référencés sur la page "Cours et Tutoriels Java" (http://java.developpez.com/cours/). Comment ce fait-ce ?

[Ricky81]

Tiens, en passant, ces tutos ne sont pas référencés sur la page "Cours et Tutoriels Java" (http://java.developpez.com/cours/). Comment ce fait-ce ?

Pas encore, ils sont assez récent.

[zonez]

Salut, est-ce que quelqu'un a déjà essayé echo2 de nextapp, des commentaires?