IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Débat : Quel est votre framework Web préféré en Java ?

Le , par Pill_S

37PARTAGES

1  0 
Quel est votre framework préféré de gestion de Vue?
JSF (Java Server Faces)
34 %
Struts v2
14 %
Spring MVC
12 %
Struts v1
10 %
GWT
10 %
Wicket
8 %
Tapestry
5 %
Autres (précisez)
8 %
Voter 305 votants
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!)

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Pill_S
Membre expert https://www.developpez.com
Le 22/10/2007 à 10:45
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...
2  0 
Avatar de fisico
Membre régulier https://www.developpez.com
Le 22/10/2007 à 10:37
JSF parce que c'est une spécification.
1  0 
Avatar de sinok
Expert éminent sénior https://www.developpez.com
Le 22/10/2007 à 1:53
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
0  0 
Avatar de gronono
Membre confirmé https://www.developpez.com
Le 22/10/2007 à 5:12
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
0  0 
Avatar de Wyfrel
Membre à l'essai https://www.developpez.com
Le 22/10/2007 à 11:40
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.
0  0 
Avatar de sinok
Expert éminent sénior https://www.developpez.com
Le 22/10/2007 à 11:51
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é.
0  0 
Avatar de fisico
Membre régulier https://www.developpez.com
Le 22/10/2007 à 12:49
Citation Envoyé par Pill_S Voir le message
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?
0  0 
Avatar de Pill_S
Membre expert https://www.developpez.com
Le 22/10/2007 à 13:28
Citation Envoyé par fisico Voir le message
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).
0  0 
Avatar de joseph_p
Membre expérimenté https://www.developpez.com
Le 23/10/2007 à 16:58
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 
Avatar de joseph_p
Membre expérimenté https://www.developpez.com
Le 25/10/2007 à 12:56
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
0  0