[Doc]Reflexion sur l'état de l'art
Bonjour ;
Cela fait plusieurs jours que je me suis décidé à réaliser un petit état de l’art sur les frameworks Web tiers actuels et les standards incontournables du futur proche.
Actuellement lorsqu’on évoque les framework Web, une liste toujours presque identique nous est présentée. A savoir :
• Struts 1.X
• Spring
• WebWork2
• Tapestry
• Cocoon
• JSF
Mais également Struts-Shale, myFaces et Sun JSF-RI et les frameworks clients legers riches basés sur « Ajax ».
En même temps le web2.0 est en pleine effervescence, durant de nombreuses années, l’évolution des applications clients legers n’a concerné que la partie serveur, ce qui n’est pas une mauvaise chose en soit mais le coté client s’est donc trouvé laissé pour compte ainsi que l’utilisabilité des interfaces web (même si des grands pas ont été fait avec CSS etc…). Aujourd’hui avec la maturité des navigateurs et l’essor d’Ajax et XUL on est en passe de « révolutionner » la manière de naviguer sur le net.
C’est identique avec JSTL, JSF, taglibs_struts… pour le design des IHM web. Avec JSF et cette nouvelle manière de penser les interfaces, des outils RAD peuvent désormais s’appuyer sur ce standard pour améliorer l’activité des designers.
Le souci c’est qu’aujourd’hui cette effervecence provoque des mots de tetes aux chefs de projet. En effet si la multitude d’outils est un point positif, dans quelques mois, parmis eux nombreux seront les projets abandonnés/fusionnés en cours de route. La standardisation comme la selection naturelle est implacable. Mais dans un environnement économique, la pérénité d’une solution est indispensable pour garantir le contrôle des couts, des ressources humaines, etc…
La grande problèmatique dans un développement et l’organisation d’un projet est de trouver des outils capables de séparer les domaines de compétences. Les frameworks Web tiers du moment sont arrivés à un niveau avec MVC model 2 qui permet plus de souplesse dans l’organisation des équipes. JSTL marque une standardisation des librairies.
Mais voila qu’arrive JSF à grande pompe. myFaces premiere implementation OSS qui a pris une belle avance sur JSF-RI. Shale un framework completement repensé de Struts dont le but est d’intégrer une implementation de JSF (myFaces ou JSF-RI par exemple) et de fournir autour des fonctionnalités à valeurs ajoutées.
La question est aujourd’hui en l’état actuel des choses, pour des projets existants doit-on préparer une future migration en douceur ou attendre un meilleur retour d’expérience sur JSF. Doit on alors commencer à integrer JSF à Struts 1.X ou peut dont déjà débuter des projets sur Shale. Quand sera-t-il de JSF ? Si l’avance de myFaces est indiscutable sur JSF-RI, Sun ne va-t-il pas rattraper et même devancer demain « son concurrent » ?
Doit-on conseiller aux entreprises de rester sur leur schéma traditionnel STRUTS, SPRING ou autres ou adopter le modèle par composant immédiatement sur leur base actuelle ? Doit-on leur affirmer que les RAD travaillant avec JSF sont performants ou non ?
L’environnement ASP.NET rassure par sa consistence et l’objectif est de savoir si avec J2EE ont peux désormais proposer la même chose.
C'est un peu fouilli je digère grande quantité de données mais c'ets à l'image de l'état des outils J2EE d'aujourd"hui.
[Modéré par Didier] : ajout de tag dans le titre - Les règles du forum Java
Re: [Doc]Reflexion sur J2EE etat de l'art
Citation:
Envoyé par grosFab
Bonjour ;
Cela fait plusieurs jours que je me suis décidé à réaliser un petit état de l’art sur les frameworks Web tiers actuels et les standards incontournables du futur proche.
Actuellement lorsqu’on évoque les framework Web, une liste toujours presque identique nous est présentée. A savoir :
• Struts 1.X
• Spring
• WebWork2
• Tapestry
• Cocoon
• JSF
Mais également Struts-Shale, myFaces et Sun JSF-RI et les frameworks clients legers riches basés sur « Ajax ».
Doit-on leur affirmer que les RAD travaillant avec JSF sont performants ou non ?
C'est un peu fouilli je digère grande quantité de données mais c'ets à l'image de l'état des outils J2EE d'aujourd"hui.
Oui, la bonne nouvelle avec Java, c'est qu'on a le choix, mais c'est aussi une mauvaise nouvelle car il faut faire ce choix en connaissance de cause....
Attention de ne pas confondre standard et implémentation (JSR vs. JSF-RI) d'une part et projet open source et standard JCP d'autre part (Tapestry vs. JSF).
Je suis suis curieux d'avoir des détails sur les différences JSF-RI et myFaces.
Pour ce qui est de la productivité des outils RAD avec JSF, je pense que c'est réel (mais bon, je ne suis pas neutre).
