[Choix] Quel framework est le plus indiqué dans mon cas ?

Bonjour à tous.

J'aimerais avoir vos avis sur quel(s) framework(s) utiliser pour des projets futurs. Je sais qu'il y a déjà eu pas mal de discussions à ce propos dans le forum j'ai fait quelques recherches (notament celui-ci) mais je ne parviens pas à me décider. Je me suis dit que peut-être en précisant mon cas vous pourriez me donner des conseils encore plus avisés :).

On est une petite équipe de développement Java (3 - 4 personnes), et on sort d'un développement où l'on a utilisé simplement les JSP/Servlet, Hibernate (qu'on va conserver vu qu'on s'est fait une petite expérience dessus et qu'on en est content). En Ajax on a utilisé AjaxTags que je trouve vraiment simple d'emploi et pour l'utilisation de JSP/Servlet je trouve que ça convenait super bien. Lors de mes recherches j'ai vu DWR qui a l'air "plus lisible" mais je suis aps sur que ça vaut le coup de ne plus utiliser AjaxTags enfin si celui-ci se prète toujours aux nouveaux choix de framework que l'on va faire. Mais bon pour le reste, c'était franchement mal pensé parce que les analystes qui ont pondu l'architecture globale n'avaient jamais fait de web...

Et comme il y a de nouveaux projets qui arrivent, j'aimerais leur proposer au moins une solution moins archaique.

Mon boss est tenté par JSF (en partie parce que c'est une certification Sun) mais personnelement j'ai fait quelques recherches dessus, et lu "Ajax on Java" de O'Reilly et je trouve que c'est vraiment tiré par les cheveux pour mettre un peu d'ajax avec JSF (et aussi ce que j'ai lu comme le "XML hell" ça je trouve plutot lourd aussi)... Enfin c'est peut être pa sune fatalité pour l'ajax, j'ai cru comprendre qu'il y avait moyen d'utiliser un framework comme RichFaces qui simplifiait cela? Mais bon pour le XML hell là j crois que ça fait partie de JSF... ?

Dans mes recherches, j'ai eu l'impression que ce serait plus "facile" de combiner Struts avec de l'Ajax mais bon c'est peut être qu'une impression de surface... Et j'ai lu dans les différents topics ici pas mal de choses intéressantes comme Wicket qui a l'air pas mal du tout.

Les priorités que ma hiérarchie apprécieront :
1) le temps de développement
2) une certaine facilité pour faire "joli" (on a pas de graphiste ou quelqu'un pour s'occuper du design donc si on peut facilement faire quelque chose qui rend bien ça nous arrange)
3) stabilité du framework (pas une technologie qui change du tout au tout entre chaque version, pour citer un exemple je crois que Trapestry est de ce genre que l'on veut éviter)
4) lisibilité du code, pas de "XML hell", etc

Et puis on comtpe garder hibernate, utiliser peut-être Swing mais pas forcément pour la gestion de vue et pour le reste j'espère que vous pourrez m'éclairer!

Merci d'avance :)

Pour du développement web, je te conseillerais jsf ou struts v1.
Le premier est vraiment prometteur et fiable à l'heure actuelle.
Couplé à RichFaces, c'est encore mieux d'un point de vue look et possibilités (l'ajax étant intégré aux composants). La dernière version me semble stable (suffisamment) mais je suis en train de faire le tour de la question pour nos propres développements futurs.

Struts v1 reste très performant et simple, il y a une grande base documentaire, c'est hyper fiable. Au niveau look, couplé à struts-layout, on a vraiment tout ce qu'il faut pour développer des applications puissantes et robustes (il n'y a guère que ces :evilred: de checkbox qui prennent le chou, mais ça n'est pas lié à struts-layout, c'est général).
Pour ce qui est de l'ajax, rien n'empêche d'appeler un contrôleur struts, donc, que ce soit par du code javascript ou par une bibliothèque (comme celle dont tu parles), il ne devrait pas y avoir de problème.

Struts v2 sera (peut-être) bien dans le futur, mais à l'heure actuelle, ça manque de documentation...

Hibernate est un très bon choix, rien n'empêche d'ailleurs de l'utiliser comme JPA avec des EJB3 Entity (encore mieux je trouve)

Ça n'est qu'un avis

Bon choix ;)
A+

Bonjour,
Je crois que tout d'abord, vous devez faire un choix entre non pas les frameworks mais plutôt sur le type de framwork à utiliser: procudural ou par composants.
Dans la première catégorie, tu as Struts, Spring MVC, WebWork, etc.
Dans la seconde, tu as principalement JSF, Wicket et Taperstry.

Pour répondre à OButterlin à propos de Struts 1.x, amha, Le choisir pour développer un nouveau projet est tout simplement faire l'autruche: on a peur de voir ce qu'il y'a ailleurs, on s'en sort très bien avec celui là (affirmation toute relative vu la rigidité de ce framework), alors gardons le ;)

Maintenant, pour répondre à quelques point evoqués par ptr83:

Citation:

---

et lu "Ajax on Java" de O'Reilly et je trouve que c'est vraiment tiré par les cheveux pour mettre un peu d'ajax avec JSF (et aussi ce que j'ai lu comme le "XML hell" ça je trouve plutot lourd aussi)

---

Humm ... je comprends vraiment pas ta position la dessus, vu que JSF nu n'offre strictement rien pour Ajax.

Seulement, il a été conçu d'une façon très ouverte aux extensions, et ainsi on peut maintenant trouver des jeux de composants super-bien faits supportant l'ajax comme Ajax4jsf: Je doute fort qu'on puisse faire plus simple comme moyen de faire l'ajax sans JS via des tags XML.
Pour ce qui est du XML-Hell ... J'émets mes reserves la dessus, surtout que tu voiens du monde JSP/jeux de tags, 100% basés sur le XML.
JSF y va de la même façon, mais en plus abstrait, i.e tu ne trouves que très rarement du HTML dans une page JSF.

Pour ce qui de la configuration, Je ne crois vraiment pas que le XML pose problème avec le tooling qu'on a aujourdhui supportant JSF (eclipse webtools 2 et Netbeans): le tout se fait via souris.
En ajoutant Spring > 2 à l'equation, plus de la moitié de l'XML est viré (en faisant que Spring gère les managed beans de JSF).
De toute façon, le XML-Hell est commun à 90% des frameworks web java, y compris Struts.

Sinon, je crois sincèrement que JSF + facelets + RichFaces + Spring + IDE décent permettent de mettre sur pied rapidememnt des applications Ajax et surtout zolies out-of-the-box grâce à Richfaces, une fois qu'on maitrise les technos en question bien sûr ;).

Seulement, je dois admettre que se sentir confortable avec JSf peut prendre du temps.

Wicket par contre n'utilise pas du tout de l'XML, est orienté composants et surtout orienté Objets. Il est aussi délicat à maitriser, à cause notamment de la notion des modèles.

Mais ce qui peut poser problème (ppour toi en particulier) est qu'il n'offre pas un jeu riche de composants solies out-of-the-box.
A l'inverse de JSF, Wicket ne fait pas de la magie en générant entièrement les pages HTML. au contraire, il reste non-instrusif et c'est au développeurs de fournir la majorité du HTML.

Remarque qu'en investissant dans l'acquisition d'un beau template (vraiment pas cher), ou encore utiliser une solution comme YUI ou ExtJS, cet argument est annihilé.

Mais pour être tout à fait franc avec toi, le mieux serait de consacrer du temps à evaluer soi-même quelques un des frameworks les plus populaires, au lieu de relier complètement sur les retours d'expériences des autres ;)

Citation:

---

Envoyé par djo.mos

Le choisir pour développer un nouveau projet est tout simplement faire l'autruche: on a peur de voir ce qu'il y'a ailleurs, on s'en sort très bien avec celui là (affirmation toute relative vu la rigidité de ce framework), alors gardons le ;)

---

Damned ! Quand j'ai écrit ça, il était dans mon intention de préciser que c'était dépassé et qu'il n'y avait plus d'évolutions notables sur ce framework (gros oubli :aie:)

Heureusement, que tu passais pas là... ;)

je plusoie la facilité de JSF + facelets + RichFaces. Richfaces est vraiment bien foutu pour de l'ajax, tu peux associer à des composants non ajaxifié des évènement richface qui vont les ajaxifier. Exemple, tu prendre un inputText de base (non-ajax) et tu lui branche un évènement onChange qui va redessiner un panel en dessous du formulaire :D. Et tout çà avec un seul tag "ajax" a rajouter en child de l'inputText. Tu peux vraiment redessiner partiellement ton formulaire jsf, faire apparaitre / disparaitre des bout complet du formulaire dynamiquement et le tout sans écrire un pet javascript :p

Quand au "xml-hell", la difficulté de jsf réside surtout dans la définition des managed-bean et des règles de navigation. Hors, pour les managed bean , tu peux facilement faire un sous-projet pour une catégorie de bean avec les managed beans configuré via un META-INF/faces-config.xml Donc tu maitient tout çà en sous projets bien clair. JSF se charge de scanner tout les jars au démarrage :D

Personnellement, j'ai vu le bond qu'on a fait au boulot en passant de struts1 à JSF, çà va, comme dirait le bucheron, "hachement plus vite". En deux mois de boulot, une appli contenant des formulaire de plus de 200 champs a été mise en place (ajax indispensable pour alléger les trajets client / serveur de ce paquet de données). Y a que le submit final qui se faisait pas en ajax ^^

Bonjour à tout le monde,
Depuis deux jour, je suis en train de chercher sur le meme sujet.
Dans le cadre de mes études, je dois réaliser un site web d’une conférence suivant une architecture MVC. Et pour cela je dois choisir entre: JSF, Spring et Struts.
Je vous demande de me conseillez, et je demande si quelqu'un peut m'indiquer la ou je peux trouver une étude comparative?
Je compte sur vos conseils et j’attends vos réponses.
Merci d’avance.

Citation:

---

Envoyé par OButterlin

La dernière version me semble stable (suffisamment) mais je suis en train de faire le tour de la question pour nos propres développements futurs.

---

Ce serait très sympa de nous tenir au courant :)

Citation:

---

Envoyé par OButterlin

Hibernate est un très bon choix, rien n'empêche d'ailleurs de l'utiliser comme JPA avec des EJB3 Entity (encore mieux je trouve)

---

Par contre là j'ai un peu de mal à te suivre :oops:

Citation:

---

Envoyé par djo.mos

Je crois que tout d'abord, vous devez faire un choix entre non pas les frameworks mais plutôt sur le type de framwork à utiliser: procudural ou par composants.
Dans la première catégorie, tu as Struts, Spring MVC, WebWork, etc.
Dans la seconde, tu as principalement JSF, Wicket et Taperstry.

---

Question surement idiote mais bon je la pose tout de même : hormis que l'un se base sur les actions et l'autre sur les objets... Qu'est ce que je dois regarder dans mes projets qui doit me faire pencher pour une solution ou pour l'autre?

Citation:

---

Envoyé par djo.mos

Humm ... je comprends vraiment pas ta position la dessus, vu que JSF nu n'offre strictement rien pour Ajax.

---

C'est peut-être justement ce qui m'a surpris... Vu l'importance d'utiliser de l'Ajax de nos jours, je m'attendais à trouver des "solutions ajax intégrées" au sein même de JSF. Enfin comme tu l'as expliqué en fait il suffit d'utiliser des extensions mais quand j'ai un peu survolé quelques exemples de JSF "de base" (sans ces extensions justement) ça m'a vraiment surpris :oops:.

Citation:

---

Envoyé par djo.mos

Remarque qu'en investissant dans l'acquisition d'un beau template (vraiment pas cher), ou encore utiliser une solution comme YUI ou ExtJS, cet argument est annihilé.

---

L'investissement (si petit soit il) pour le template ce n'est pas envisageable :( c'est bète mais bon c'est comme ça dans ma boite -_- ...
Sinon ExtJS j'ai un peu fouillé et ça donne pas mal du tout :) c'est peut-être une alternative [ ExtJS + Wicket ] au [ JSF + facelets + RichFaces ] que tu as précédement proposé non?

Citation:

---

Envoyé par djo.mos

Mais pour être tout à fait franc avec toi, le mieux serait de consacrer du temps à evaluer soi-même quelques un des frameworks les plus populaires, au lieu de relier complètement sur les retours d'expériences des autres ;)

---

Oui je sais :oops: le problème c'est qu'on refuse de me donner du temps au boulot pour ces recherches :( donc je me la tape chez moi... Je suis motivé mais bon pas au point de me farcir des recherches approfondies sur plusieures solutions sur mon temps libre à la maison :oops:. Je vais en choisir une, la creuser autant que je peux et essayer de proposer quelque chose d'intéressant.

Citation:

---

Envoyé par tchize_

Quand au "xml-hell", la difficulté de jsf réside surtout dans la définition des managed-bean et des règles de navigation. Hors, pour les managed bean , tu peux facilement faire un sous-projet pour une catégorie de bean avec les managed beans configuré via un META-INF/faces-config.xml Donc tu maitient tout çà en sous projets bien clair. JSF se charge de scanner tout les jars au démarrage :D

---

J'ai pas compris ce passage :oops: mais je vais faire quelques recherches là dessus :).

En tout cas merci pour vos avis, pour peu que ce soit bien un framework "composant" qui soit le plus indiqué, je vais finir par pencher vers [ JSF + facelets + RichFaces + Spring + IDE ] (comme IDE on utilise rational d'IBM mais bon comme il est basé sur eclipse peut etre autant desuite migrer vers celui ci) voir [ ExtJS + Wicket ] mais bon ça a l'air moins probable.

Pour faire simple, EJB3 Entity définit une "norme" qui s'appuie sur une API de persistance (JPA) tierce.
Tu peux faire de l'Entity en utilisant Hibernate (c'est le défaut pour un serveur JBoss) ou Toplink (Sun) ou JDO.
Avec les Entity, dans la mesure où tu n'utilises pas de fonctionnalités propriétaires, tu peux passer d'une implémentation JPA à l'autre sans modification de l'application.
Avec la "norme", on a déjà tout ce qu'il faut pour développer une application d'envergure même si certaines fonctionnalités d'hibernate (pour les tris de Set par exemple) manquent à mon sens.

Pour l'IDE, l'outil d'IBM est très largement au-dessus d'Eclipse, donc, inutile de le changer (curieux choix d'ailleurs pour une société qui refuse d'investir le moindre kopeck pour un outil de template ;))

A+

Pour Rational c'est une histoire d'AS400 dans la société qui nous permet de l'utiliser sans frais.
Si je pensais changer c'est que certains plug in pour eclipse ont des problèmes de compatibilité avec.

Merci pour tes précisions sur EJB3 / JPA.

Bonjour,

Citation:

---

Envoyé par ptr83

Question surement idiote mais bon je la pose tout de même : hormis que l'un se base sur les actions et l'autre sur les objets... Qu'est ce que je dois regarder dans mes projets qui doit me faire pencher pour une solution ou pour l'autre?

---

Bah en général, l'approche composants est plus adapté aux projets avec des IHMs super-complexes, vu le haut niveau d'abstraction qu'elle introduit.
Mais du coup, tu perds un peu de contrôle sur le bas niveau ... c'est un peu comme pour un langage de programmation OO moderne et l'assembleur.

Citation:

---

Envoyé par ptr83

C'est peut-être justement ce qui m'a surpris... Vu l'importance d'utiliser de l'Ajax de nos jours, je m'attendais à trouver des "solutions ajax intégrées" au sein même de JSF. Enfin comme tu l'as expliqué en fait il suffit d'utiliser des extensions mais quand j'ai un peu survolé quelques exemples de JSF "de base" (sans ces extensions justement) ça m'a vraiment surpris :oops:.

---

Oui, je comprends ton point de vue, mais faut aussi voir que la dernière version JSF date déjà d'un peu, ce qui peut expliquer ça ... mais bon, même sans ajax, tu vas certaienemtn utilser des jeux de composants, car ceux de base sont limités... c'est jsutement dans l'esprit de JSF: il est fait pour être étendu.

Citation:

---

Envoyé par ptr83

Sinon ExtJS j'ai un peu fouillé et ça donne pas mal du tout :) c'est peut-être une alternative [ ExtJS + Wicket ] au [ JSF + facelets + RichFaces ] que tu as précédement proposé non?

---

Envisageable, mais techniquement difficile à mettre en place: surtout pour ExtJS qui est basé sur JavaScript pour batir les IHMs, tandis que Wicket est orienté Markup.

Citation:

---

Envoyé par ptr83

Oui je sais :oops: le problème c'est qu'on refuse de me donner du temps au boulot pour ces recherches :( donc je me la tape chez moi... Je suis motivé mais bon pas au point de me farcir des recherches approfondies sur plusieures solutions sur mon temps libre à la maison :oops:. Je vais en choisir une, la creuser autant que je peux et essayer de proposer quelque chose d'intéressant.

---

Bof ... choisir une et ensuite tester ? ... Je te propose ceci: limiter à deux et les tester, comme ça, tu pourrais faire un choix fondé ;)

Citation:

---

Envoyé par ptr83

En tout cas merci pour vos avis, pour peu que ce soit bien un framework "composant" qui soit le plus indiqué, je vais finir par pencher vers [ JSF + facelets + RichFaces + Spring + IDE ] (comme IDE on utilise rational d'IBM mais bon comme il est basé sur eclipse peut etre autant desuite migrer vers celui ci) voir [ ExtJS + Wicket ] mais bon ça a l'air moins probable.

---

Oui, je crois sincèrement qu'un framwork composants est plus adapté pour un nouveau projet, quel qu'il soit.
Reste à choisir: GWT, JSF, Wicket, Taperstry, etc. etc.

Je peux te parler un peu de JSF et de wicket.
Les deux sont orientés composants, à la différence près que JSF génère du HTML tandis que Wicket manipule le HTML.

Dans JSF, tut oucheras rarement du HTML: tu décris tes IHMs via XML (n'envisages mêem pas d'utiliser les JSP, plutôt facelets), ce qui peut être chiant mais plus adapté aux développeurs sans équipe webdesign.

Wicket a une autre approche: il esai au max de rester non intrusif, et te permet plutôt de manipuler le HTML plutôt que de le générer (répéter un bloc, ajouter/modifier un attribut, associer un comportement à un élément, etc.)
C'est très propore à mon avis comme approche, et te permet d'avoir beaucoup plus de contrôle sur le résultat que pour JSF, mais ça nécesite une connaissance en HTML et que tu écris tes HTMLs ;)

Sinon, l'approche full-Java et OO de wicket le rend, en tout objectivité, plus puissant que JSF.
JSF lui utilise plusieurs couches/technos: XML pour les IHMs, JAva pour les managed beans, EL pour faire le lien entre les deux, etc.
C'est en quelque sorte une évolution des frameworks action, pas une révolution.
JSF est élégant et expressif, mais l'EL par exemple ne sera jamais plus puissante/expressive qu'unlangage turing-complet comme Java, c'est pour cela que je dis que Wicket est plus puissant.

Mais attention, je ne veux surtout pas te fausser en te peignant la vie en rose: J'en ai vu des vertes et des pas mûres avec JSF et avec Wicket.

Avec JSF car si un truc dans ta page ne marche pas, t'as exactement 0 contrôle sur le HTML généré, et tu retrouves à faire des quirks pour t'en sortir.

Pour wicket: il est vraiment difficile à maitriser, mais c'est normal pour un truc de cette puissance.

Aussi pour JSF, le tooling laisse à désirer, du moins côté eclipse et si on fait du vrai développement avec JSf.
Non mais si on joue seulement avec (JSP, pas de Spring, etc.), c'est impressionnant au début, mais dès qu'on travaille sérieusment la dessus, avec Facelets/Spring, eclipse te laisse seul dans le pétrin, et je me retrouve à taper tout le XML + toutes les EL sans auto-complétion.

Problème inexistant pour Wicket, car basé à 95% sur Java, là, aucun problème d'auto-completion ;)

Je pourrais passer des siècles à t'en parler, mais faut bien arrêter un moment ou l'autre :aie:

@+

Merci je vais analyser ça et méditer ^^

J'ai pas tout lu, mais ça

Citation:

---

Envoyé par djo.mos

Pour wicket: il est vraiment difficile à maitriser, mais c'est normal pour un truc de cette puissance.

---

ça m'a fait bondir!

NON! Wicket n'est pas compliqué! Bien sûr, avec la simple doc et les exemples, c'est un peu coton, mais avec la mailing list plus aucun souci!!

En tout cas, je n'ai jamais ressenti de difficulté particulière. J'ai fait tout ce que je devais faire très facilement et très proprement...

Y'a qu'à lire ma signature pour comprendre que j'en suis tombé amoureux :yaisse2:

;)

Bonjour,
J'ai dit difficile à maitriser, pas à apprendre ou à utiliser ;)

Il existe effectivement quelques coins d'ombre infestés de mauvais esprits. :aie:
je pense notamment aux:
- Les models : notion pas tellement commune dans les fwks web. ça peut bloquer au début, quel model choisir ? quand chainer ? etc. pourquoi le LoadableDetachable ?
- Les contraintes des inner classes/anonymous classes. ça c'est à cause de Java, mais Wicket repose sur ces choss là
- Les pièges mémoire: les attributs des pages seront sérialisés, etc.
- Le fait que c'st stateful par défaut: la même page est resservie si pas de setResponse, ce qui peut désorienter plus d'un.
- Le fait qu'on construit une page dans le constructeur, qui n'est invoqué qu'une seule fois pour une seule instance, ce qui exige de faire attention à comment construire ses composants/models pour qu'ils ne soient pas statiques.
- etc.

Et c'est tout à fait vrai que la mailing-list de Wicket est du pain béni avec les développeurs core de Wicket qui sont tout le temps là à répondre ;)

Mais je crois vraiment au potentiel de Wicket, d'ailleurs, nous sommes en train d'envisager d'y migrer au boulot ;)

Seulement, il ne faut pas le prendre à la lègère: c'est du coustaud.