juin
2008
Un article de djo.mos
Le groupe d’experts de la JSR 314 (connu plus sous le nom moins barbare de « JSF 2.0″) a publié la première version des specs (Early Draft Review : EDR) et sollicitent les retours de la communauté.
Cette EDR peut être téléchargée ici.
Remarque que dans la page de téléchargements, on peut aussi récupérer les javaDocs des différentes classes constituant l’API de JSF 2.0.
J’ai survolé rapidement l’EDR, et force est de constater que c’est pas destiné pour le commun des mortels … pire encore, il est difficile de séparer ce qui est nouveau (JSF 2.0) de ce qui ne l’est pas (JSF 1.2 ou antérieurs).
Je vais donc me contenter de poster ici ce qui est promis par le groupe d’experts dans la page de la JSR:
- Fournir un mécanisme simplifié pour l’agrégation de composants: facelets ermet déjà de faire cela.
- 0 conf, ou encore plus de web.xml ni de faces-config.xml: passer par les annotations quand c’est possible
- Un mécanisme similaire au stages de Wicket (production/developement)
- Améliorer la gestion d’exceptions: il en etait temps !
- Éliminer le besoin d’écrire un TagHandler JSP pour les composants: à mon avis, meiux vaut virer complètement le JSP de l’équation
- Inclure une vraie technologie de présentation qui sera inspirée de faclets et de JSFTemplating
- Éliminer la phase déploiement: ça, c’est vraiment trop beau pour être vrai à mon avis. la solution proposée serait de passer par des scripts (au lieu de java, mais ça ne me parait pas aussi génial que ça) mais aussi changer les specs de l’Exploded WAR pour tenir compte de trucs spécifiques à JSF
- Modifier le lifecycle d’une requête pour tenir compte de l’AJAX
- Séparer « build the tree » et « render the tree » en deux phases séparés
- Permettre le traitement partiel du tree via AJAX (pour améliorer les performances)
- GET GET GET GET : le talon d’Achille de JSF: utiliser le GET autant que possible
- Validation côté client
- Une vraie fondation pour la gestion de ressources
- Ajout de quelques composants clés: Sélection de Date, upload de fichiers, arbre, onglets, etc.
- Fournir un moyen pour invoquer un traitement (via ajx si possible) au chargement d’une page
- Utilisation de deltas (liste de changements) au lieu du tree complet
- repenser la gestion d’états de composants pour rendre le stateless l’état par défaut
- Un mécanisme de communication inter-page, comme par exemple le conversational scope
- Un framework de contrôle côté client (en Java Script)
- Support du REST
- etc.
Bref, vu comme ça, ça a l’air alléchant mais attendons de voir quelque chose de concret.
Mais pour tout vous dire, j’ai vraiment été déçu par JSF 1.x : problèmes de performances, d’utilisabilité, phase de développement très pénible, trop de XML, difficulté de développement de composants (et ne me dites pas que c’est pas difficile: allez voir Wicket et on en reparlerait), etc. alors j’espère vraiment que JSF 2.0 pourrait redresser un maximum de ces défaillances.
arf enfin des choses sympa du coté de JSF. Parce que sauf à utiliser Seam je ne vois pas trop l’intérêt de ce Framework (que j’utilise pourtant au taf).
A savoir, si l’arrivée des premières implémentations se fera avant que je soit complètement fan de grails …
Par ailleurs, il faudra voir aussi le coût de montée de version parce que pour le coup beaucoup de choses ont l’air d’avoir changé.