Je bosses actuellement sur une appli web dévelloppée en JSP/Servlet classique avec quelque Bean.
 
Je dois prochainement la récrire et la passée en Struts mais en recherchant un peu et en discutant avec quelques amis les grosses société se mettent à JSF.
 
Je connais un peu Struts mais pas du tout JSF.
Je n'ai trouvé que de vieux messages sur ce forum concernant JSF.
 
Il y a t il eu des nouveautés?
 
Mon autre problème est que j'utilise tomcat version 5.0 est ce compatible avec JSF ou faut il changer de serveur d'application ?
 
Si ceux utilisants JSF et connaissant Struts pouvaient me donner leurs avis je leur en serai reconnaissant.

je ne sais pas si c'est un facteur important pour toi, mais je suppose qu'avec JSF tu trouveras beaucoup moins d'informations (bouquins, tutorial, forums) que pour Struts

La doc n'ai pas le point important.  
Le seul truc important c'est que je n'ai pas envie, et surtout pas le temps, de réécrire l'appli en Struts pour la passer ensuite en JSF.
 
En gros est ce que JSF est suffisament rôdé pour pouvoir être utilisé?
 
Est ce que Struts sera abandonné au profit de JSF?
 
Est ce que le passage à JSF est compliqué pour des programmeurs connaissant déjà Struts?

Est-ce que quelqun utilise jsf ?
Ca m'étonnerait...

ni l'un ni l'autre, telle est ma réponse.

(sinon oui, jsf est "pret" )

t'as pu tester ?
 
je suis assez intéressé par un retour d'expérience ...

 
Moi aussi.  
 
(J'ai un peu regardé et je trouve que JSF sans ide ad-hoc, c'est un peu imbitable.)

non, mais vu les bouts de conférences à javapolis, vu les sujets ça avait l'air assez avancé, puisque ce n'etait plus des sujets genre "overview"
 
 
 
(... pret à voler à la poubelle quoi )

tiens, Webwork quelqu'un a déja essayé ? retour d'expériences ?

moi, jsuis fan

faudrait que je me penche sur Struts, je risque d'en avoir besoin en stage

Une autre alternative interessante est Tapestry, un peu dur a prendre en main au debut mais apres c'est vraiment tres elegant et agreable a utiliser (je l'utilise avec Spring )

je plussoie allègrement, Tapestry est très puissant et agréable à utiliser. Et il est pas si dur que ca à prendre en main

moi j'utilise webwork avec pico/nanocontainer

très probablement orienté, mais bon:
http://wiki.opensymphony.com/displ [...] +to+Struts
 
Si qqun à un document d'introduction rapide à Tapestry, je suis preneur.

 
 
une autre comparaison Struts, Spring MVC, Webwork, JSF, Tapestry
 
https://equinox.dev.java.net/framew [...] eworks.pdf
 
btw, Matt Raible a créé une web appilcation de base Appfuse https://appfuse.dev.java.net et plusieurs web frameworks sont utilisés : struts, Spring MVC, Webwork, JSF, Tapestry
Les personnes qui sont à la recherche du web framework qu'ils vont utiliser pour leur prochaine application, ca vaut ptet bien la peine de jetter un oeil à Appfuse
 
plus d'infos à propos d'Appfuse :  

ouaip, j'ai vu ça... mais son integration webwork est toute récente et il ne maitrise pas trop je crois (c'est un fan de struts à la base il me semble?); et pis il a pas picocontainer
 

 
il a pas picocontainer, mais il a spring qui fait plus ou moins la même chose, non ?

oui, en bcp plus complet.  
pico n'est *que* un container d'IOC, qui à la base ne gere que le CDI (constructor dependency injection); avec des "extensions" fournies par nanocontainer, il gere aussi les SDI (setter dependency injection), et qques modules d'integration (j'utilise l'integration ejb et webwork avec succès)
 
Spring, que je ne connais pas vraiment, est un container d'IOC, mais qui à la base est basé sur la SDI. Et Spring semble avoir *beaucoup* d'autres modules, qui ne sont pas uniquement des extensions mais un framework en soit. (un truc developpé "pour" pico peut etre utilisé partout, alors qu'un composant qui utilise spring est forcément lié à spring s'il dépend de ces fameux modules)
 
(et perso, je prefere le CDI au SDI, c'est moins verbeux et ça me parait plus propre - après, y'a des cas ou on ne peut pas se contenter d'SDI, mais là n'est pas la question)

Oui Spring est plus qu'un container IOC, il propose des module s comme la gestion de la couche DAO, le support Hibernate, il a un super module pour gerer la securite Acegi. De plus, on peut faire de l'AOP de maniere declarative ...  
 
Le meilleur point depart pour tout ceux qui veulent decouvrir cette plateforme je vous conseille fortement de regarder cette appli : http://sourceforge.net/projects/hispacta
C'est un exemple d'un intranet qui utilise comme technologie  : Spring + Acegi, tapestry et hibernate. Il utilise une grande partie des fonctionnalitees de spring que j'ai cite plus haut. Son archi repose asssez bien sur les principes etablis dans l'excellent livre better, faster, lighter java de Bruce Tate et Justin Gehtland chez O'Reilly
 
the real moins moins> Comme point de depart pour tapestry je te conseille de regarder ce tutal : http://tapestry-tutorial.cloudnine [...] rial2.html  
puis de regarder en profondeur l'appli hispacta.

j'ai justement déjà hispacta, parce que je compte utiliser acegi
 
A priori, acegi semble utilisable en dehors de spring (du moins j'espère), a part pê pour certaines fonctionnalités... et s'il y a vraiment besoin de spring, j'espere que ça peut s'integrer dans une appli qui n'utilise pas spring à la base
 
Tu connais bien acegi?

Mouais acegi , c'est pas le module que j'ai etudie le plus mais c'est sur ma liste des todo

bon ben on doit en etre au meme point alors... ça me rebute encore un peu, notamment pour la gestion des droits d'accès aux subsets de données (je sais meme plus comment ils appellent ça)

en fait je bosse sur jetspeed en ce moment qui utilise la securite de turbine donc j'ai laisse tomber un peu acegi

 
 
 
pauvre de toi

eh oui, on choisit pas toujours ... mais je commence a maitriser la bete malgre des sources aux codages parfois chaotique ... Tu as une experience avec jetspeed ?

mon dieu oui, j'ai été forcé de l'utiliser pendant presque 2 ans, je suis bien content d'avoir *enfin* réussi à convaincre mon monde que c'était une belle daube.
 
(devoir entourer mes actions de try catch (Throwable) parce que ces niais catchent Exception et l'ignorent , sur l'execution d'une methode d'action, je l'ai pas avalé... sans parler de ces psml imbitables, de l'impossibilité d'utiliser plusieurs fenetres ou tabs d'un browser correctement, des urls qui ressemblent à rien et de la quasi impossibilité (perso j'ai tjs pas trouvé comment faire) de faire des liens entre portlets, ce qui devrait pourtant à priori etre simplissime)
 
 
 
.... sans parler du niveau proche de zero de la mailing list, ou 90% du traffic concerne des problemes d'install ou de build; comme quoi, tous les gens qui ont réussi à aller un peu plus se sont sans doute enfuis en courant?

c technique votre conversation là ...je flag en espérant que d'ici mon stage, je comprendrais...
 
à tt les coup je v faire du Struts ...(c imposé)...

Si je ne me trompe pas (je n'ai pas l'expérience requise pour pouvoir affirmer certaines choses, mais je vais tenter de m'avancer un peu), JSF c'est venu pour se positionner en face des WebForms de Microsoft.
 
En gros, on voulait pouvoir utiliser des composants "visuels" avec un comportement côté serveur de façon à:
- pouvoir composer son interface visuellement dans un IDE ad hoc
- faire en sorte que la représentation du composant soit indépendante de son implémentation (je suis pas totalement clair sur la phrase, mais quelqu'un me reprendra)
 
D'après ce que j'ai pu voir et en comparant avec un projet que j'ai fait avec Struts, JSF est un autre framework qui va gérer la requête de bout en bout à travers une servlet.
 
Si JSF est mature pour un développement en tant que telle comme le dit the real moins moins, il semble que niveau IDE ça soit pas la fête. Si l'avantage de pouvoir travailler de façon visuelle (un peu comme quand on fait du RAD) sur l'application disparaît, que reste-il comme avantage pour JSF par rapport à Struts ?
 
La question à se poser, c'est quels sont les avantages de JSF par rapport à Struts en dehors du développement proprement dit (performances, maintenabilité, compatibilité avec les serveurs d'application, facilité de déploiement) ? Si au final quand l'application est en production et qu'il n'y a pas d'avantage particulier à avoir utilisé JSF par rapport à Struts, autant utiliser Struts: ayant été très utilisé depuis quelques temps, les ressources (doc, tutos, références) sont légion. Et actuellement il est plus facile de trouver des gens qui ont des compétences Struts que JSF (même s'il est clair que ça va changer).
 
J'ai lu ça et là que Struts et JSF pouvaient cohabiter même si à l'usage JSF était bien parti pour s'imposer. C'est peut-être ce qui va te poser problème vincenzo. D'où vient l'éventualité de devoir basculer à terme en JSF ? D'une politique de la direction informatique ? D'un souçi d'harmoniser les plateformes logicielles ?
 
Je sais que je n'ai pas du t'apporter beaucoup de réponses, mais j'espère t'avoir proposé quelques questions qui pourraient te faire avancer.
 
 
 

Je déterre un petit peu le topic car je m'intéresse à JSF en ce moment. Quand je vois le nombre de "ressources" qui existent déjà sur JSF, je me dis qu'il est temps de se jeter à l'eau.
 
En ce qui concerne les IDE, JDeveloper me semble plutôt prometteur =>
http://www.oracle.com/technology/p [...] t_swf.html
 
Une page intéressante avec des tonnes de liens =>
http://www.jamesholmes.com/JavaServerFaces/

Pour info, JDeveloper semble sur le point de devenir gratuit:
 
http://www.weblmi.com/sections/art [...] roposer_j/
 
L'as-tu déjà essayé? Si oui, qu'en penses-tu?  
 
J'y jetterai un oeil le 28 juin.

Franchement JSF avec le plugin Exadel (version gratuite) pour Eclipse c'est vraiment terrible.
Il faudrait que vous essayez les tutoriels Exadel sur leur site ça calme.
Je pense que je vais passer de Struts (que je maîtrise pourtant bien) à JSF au bureau.
 
Il y a bq de doc sur le net contrairement à ce qui a été écrit ici. Je débute complétement sur JSF (j'ai commencé il y a quelques jours) mais je suis déjà très emballé.
 
On peut mélanger struts et JSF dansun même projet mais ce n'est pas la même façon de concevoir.
 
Avec struts c'est relativement séquentiel, on lance une action, on récupère les objets dans les scopes, on les manipule on redirige vers une page.
 
JSF c'est plutôt la vision "visual basic" ou "asp.net".  
Tu as une interface, une bean qui correspond derrière chaque interface, avec des listeners pour chaque bouton ou lien qui la compose.
Dans une même bean se trouve alors centralisé tous les comportements d'une interface donnée. On peut commencer à oublier de se soucier des objets request, session et du point de vue request/response. On pense autrement.
Du point de vue réutilisabilité des composants c'est très fort au niveau de la couche interface je trouve.
Regardez sur le net les composants proposés par "Apache" regroupés sous le nom "MyFaces".
Pas encore testé mais à priori tu peux créer très facilement des arbres, des menus déroulants des interfaces relativement évolué et tu ne te soucies que de les habiller un peu et de définir les listeners ou comportements grâce à une bean (qui par souci pour MVC ne devrait se contenter que d'appeler les bons objets métiers)
 
Enfin bref, pour l'instant je suis très emballé et pour répondre à la question du tout début, si j'ai un nouveau projet à faire, il vaut sauter Struts et passer directement à JSF à mon avis.
 
De toutes façons, si on est bien organisé il est très simple de passer de struts à JSF car ceux-ci ne devraient pas toucher à la couche modèle. Si tu attribues le plus de code possible à tes beans métier ça ne te coutera pas énormément de passer de l'un à l'autre ou de mélanger les deux.

Quand je lis les commentaires sur theserverside.com, il semble y avoir une grosse polémique sur JSF :
- la norme est encore trop jeune vis a vis d'autres frameworks comme Struts ou Tapestry (gros concurrent) et un petit nouveau appelé Wicket (semble très sympa lui aussi).  
- le choix de JSP et des tagslibs en tant que technologies principales pour supporter JSF n'ont pas le soutien de tous même au sein de l'equipe ayant bossé sur les specs comme Hans Bergsten
- beaucoup de developpeurs pensent (a tort d'ailleurs) que JSF est une technologie intimement liée aux outils RAD. Or les outils RAD ont toujours eu la réputation de faire des applis difficiles a maintenir.
- Struts a prouvé son efficacité sur les projets depuis qques années : choisir JSF sur un projet peut apparaitre risqué aux decideurs.
 
 
Maintenant JSF vise a etre un standard et continue d'évoluer. D'autre part la communauté Jakarta propose une implémentation JSF sympathique d'apres ce que j'ai pu lire (je n'ai testé que la JSF RI 1.1_01 : pas terrible!)
 
 
 
 
 

Quelqu'un a essaye la nouvelle implantation de Struts Shale?
Apparement ca melange Struts et JSF.
 
Sinon, que pensez-vous de Velocity?

c'est la problématique que l'on a au bureau: quel(s) framework(s) va-t-on utiliser ?
 
je plantouille donc drapal afin de (tenter de) vous suivre.

 
 
euh Shale n'a rien a voir avec Struts, si ce n'est que ce sont les memes developpeurs, enfin je crois.  
 
sinon je vous conseille de regarder Tapestry de pres, la version 3 etait fantastique, la 4 est actuellement en Beta et est tres tres prometteuse

Le probleme de Tapestry, c'est que c'est peut-etre bien joli, mais on va pas reapprendre un nouveau framework pour chaque appli.
 
Ce que je trouve chiant avec Struts, mise a part que c'est hyper lourd, c'est que l'on manipule des listes etc, mais finallement tres peu de controles sur les donnees. Des que tu veux faire quelque chose d'un peu evolue qui n'est pas juste du texte, une table, c'est la galere.
 
T'as des check box et tu veux avoir un bouton "check all"? c'est la galere...
 
Pas possible non plus d'appeler des fonctions dans tes donnees. Exemple tu fais un tableau et tu veux faire un colspan de plusieurs colonnes, ben tu fait comment pour savoir le nombre de colonnes? Tu voudrait appeler une fonction genre myData.GetNumberofBooks(artist) ben ca passe pas...
Bref, c'est vite galere et tu dois souvent mettre de Java script. En fin de compte, ca nous a ralenti considerablement.
 
Shale, Velocity ou Tapestry ou un autre rendent ils cas plus simple?
 
 

voit pas le rapport
on en peut rien si struts t'as frustré à ce point hein

webwork+picocontainer