Bonjour,
Dans le cadre professionnel, nous utilisons beaucoup Spring MVC (spécification du client) mais personnellement j'aime bien JSF pour l'approche composant !
A plus,
Mathieu
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Struts v1
Struts v2
JSF (Java Server Faces)
Spring MVC
Wicket
Tapestry
GWT
Autres (précisez)
Bonjour,
Dans le cadre professionnel, nous utilisons beaucoup Spring MVC (spécification du client) mais personnellement j'aime bien JSF pour l'approche composant !
A plus,
Mathieu
framework zk
Bonjour,
Dans le cadre de mon travail on a testé GWT et ZK, c'est le deuxième qui l'a emporté.
Ce que nous avons aprécié :
- Un peu plus flexible car il permet de travailler l'interface avec des fichiers XML. La possibilité de programmer l'interface en Java est tout de même possible.
- Il y a possibilité de créer soit même des composants plus avancés que ceux qui sont déjà proposés dans la librairie de base.
- Le forum d'entraide et les développeurs du framework sont très actifs.
- Intégration de Spring par défaut.
Pour plus de détails : www.zkoss.org
+++
vandoor
Un peu tard puisque le choix est fait...
On utilise Struts (v1) pour plusieurs projets (lourds).
C'est effectivement vieillissant, il y a pas mal d'imperfections et si ça ne tenait qu'à moi, c'est vers Struts v2 que je pencherais, mais faute de temps, ça attendra un peu...
JSF est pas mal, mais ces derniers temps, ils ont foutu un peu le bronx avec leur 2 implémentations qui s'opposent, dommage...
Un dernier truc qui m'a fait "tiquer"
Il ne faut pas confondre EJB et JPA, d'ailleurs, EJB3 peut très bien s'appuyer sur Hibernate (ou TopLink, JDO, ou d'autres)Envoyé par Pill_S
Pour avoir utilisé les 2, EJB3 a de gros avantages pour lui, mais pour une application simple, Hibernate est très bien également...
A+
Bonjour.
Veux tu détailler s'il te plaît ? c'est quoi cette histoire au juste ?
Merci.
Le choix est fait, oui, mais le débat n'en est pas moins intéressant. Et mon projet actuel n'est pas le seul que nous allons réaliser, rien ne nous empêche de changer de framework si l'un d'entre eux sort du lot
Pour EJB, je n'ai aucune connaissance, mais je ne fait que répéter les légendes urbaines que l'on voit un peu partout....
Il y avait une incompatibilité entre Sun JSF RI et ... je ne sais plus quoi, je rechercherai l'information, ça date et de mémoire, ça concernait Rich Faces...
Ca obligeait à supprimer (sur le serveur) l'implémentation de Sun... pas top...
Je vous tiens au courant (mais un peu plus tard...je suis à la ramasse)
A+
J'suis pas loin d'avoir fait la même chose avec le problème JSF... mais bon, c'était (je l'espère) peut-être un problème spatio-temporel
Moi j'ai choisis Struts 2, parce que je trouve qu'il est à la fois très facile à utiliser et très puissant surtout en ce qui concerne son intégration d'ajax dojo et les autres plugins qui peuvent rendre un grand service au developpeurs.
Humm ... bizarre ...
D'abord parceque la Sun RI est une implémentation de JSF tandis que RichFaces est un jeu de composants: ils jouent pas dans la même catégorie ...
Aussi, le "supprimer l'implémentation de Sun" sur le serveur ... sans imlémentation, JSF ne marche plus
Et enfin, je suis à cet instant même en tain de bosser sur une application JSF avec la Sun RI et RichFaces, et ça marche sans accrocs.
Pour une bonne nouvelle, c'est une bonne nouvelle !
J'aurais bien aimé développer l'application sur laquelle je travaille en ce moment avec RichFaces, à mon avis l'une des meilleurs bibliothèque de composants du moment...
Tu utilises quelle version ?
Pour ma part, je me suis orienté vers struts2. J'aime particulièrement sa gestion évènementielle très claire et simple.
J'avais un peu gouté aux approches composants (via ZK, je n'ai que survolé JSF), et leur lourdeur m'embête un peu.
Sur le client j'utilise prototype/scriptaculous pour faire de l'AJAX, donc j'ai plusieurs actions simples. J'utilise une conception de type SOA i.e. j'expose des services et je construits ma page autour, un peu l'inverse, il me semble, qu'une approche par composants qui commence par réfléchir à ses composants.
En dessous de tout ça, j'utilise Spring comme beaucoup.
Bonjour,
Ayant fait du Struts pendant quelques temps (et un peu de JSF), j'ai eu l'opportinuté de travailler sur un projet mettant en oeuvre Wicket.
Le 'tout java' permet une plus grande maîtrise du développement notamment lors des phases de refactoring. Par contre, comme le soulignait zedros, c'est du 'statefull' donc il faudra veiller 'profiler' l'application en fonction des critères de charge.
J'utilise la Sun RI 1.2_4 et RichFaces 3.1.2 GA.Pour une bonne nouvelle, c'est une bonne nouvelle !
J'aurais bien aimé développer l'application sur laquelle je travaille en ce moment avec RichFaces, à mon avis l'une des meilleurs bibliothèque de composants du moment...
Tu utilises quelle version ?
J'essayerai cette version la prochaine fois (je crois que j'avais la 3.1.0)
En tout cas, merci pour l'info
Salut à tous
Juste pour apporter ma petite et modeste contribution à cette discution, je vous propose de tester un framework que j'ai découvert il ya pas si longtemps que ça et qui m'a réellement faciné. Pour le nommer : ZK.
vous trouverez toutes les informations sur le site http://www.potix.com/.
Je ne connais pas RichFaces et Cie mais bon ..... ayant travaillé avec JSF et struts, je trouves que ZK représente l'avenir du web en java.
Merci à tous.
Un petit pdf découvert aujourd'hui qui évoque des avantages/inconvenients des frameworks : http://static.raibledesigns.com/repo...eConUS2007.pdf
Moi j'ai répondu Struts V1, mais uniquement parceque c'est le seul que j'ai déja utilisé.
Sinon, voici comment je vois les choses: les jsp de base avec biblios de tags, els, et la jstl sont largement suffisants pour générer des pages html de façon "php-like" (comprendre un petit langage impératif pratique pour générer du texte). Le vrai manque se situe au niveau de la réception des données, les servlets ne sont pas du tout adaptées pour ça, d'où l'utilité d'un framework MVC. Pour ça, Struts est suffisant, quoi qu'à mon avis il serait tout à fait possible de faire plus simple. Je fais un stage en ce moment et il est possible que j'apprenne Spring MVC, je verrais bien ce que ça donne.
Sinon, il y a évidemment d'autres approches que le MVC, l'évènementiel d'ASP.NET en est un bel exemple repris par JSF. Fut un temps où j'avais fait mon petit benchmark des frameworks web, et j'avais éliminé JSF parceque je trouvais qu'il était avant tout fait pour pouvoir implémenter un super GUI-Builder par dessus, alors qu'il n'en existait aucun bon à l'époque.
Bonjour.
La je dois dire que je ne suis pas d'accord ... JSF est bel et bien du MVC pur et dur, au même titre que les frameworks que t'a cité dans la première partie de ta réponse (Struts, etc.).
En fait, la catégorisation ne tourne pas autour du MVC (l'enfreigner serait du suicide), mais plutôt par frameworks à base d'actions (Struts, Spring MVC, etc.) et frameworks à base de composants (JSF, etc.)
Encore pas d'accord ... si on travaille en MVC (et on travaille en MVC avec les frameworks orientés composants), les services n'ont absolument rien à voir avec les vues, que ces dernières soient décrites en procedural ou en composants.
Spring + hibernate
Perso j'ai commencé par strust, par qu'on en parlait beaucoup (surtout pour les offres d'emploi), mais j'ai vite déchanté et constaté un grand nombre de limitations; je me suis dirigé vers Spring (MVC, IOC), qui est bien meilleur, avec la possibilité de tout paramétrer.
Sinon, j'utilise hibernate depuis un bout de temps, et je n'est rien testé d'autre niveau ORM, car c'est suffisament puissant.
Je cherche seulement un plugin/module pour ne pas avoir autant de fichiers/codes en utilisant Spring/Hibernate.
Je n'ai pas dit que ça avait un rapport. J'ai pas mal de "services" (j'ai dit type parce que ça renvoie des bouts de HTML ce qui ne fait pas très service), à chaque service correspond une action struts 2 qui est elle en MVC, la vue étant en HTML, mais j'envisage de rajouter du JSON. Le serveur n'a besoin de stocker dans la sessions que le compte utilisateur pour les services qui sont à accès restreints ou personnalisés pour l'utilisateur (e.g. avoir les infos de son compte).
En gros, c'est une façon simple de faire du "pseudo" composants léger avec un framework événementiel. Pour l'instant ça me convient, je dis pas que c'est l'idéal.
Répondre avec citation
Partager