Les faiblesses de Java Server Faces

Nous avons décidé de travailler finalement avec JSF pour certaines raisons. Juste au moment où nous sommes en train de nous y mettre, je tombe sur un livre qui aborde JSF et à la fin explique quelques faiblesses, je passe sur les autres qui pour moi peuvent être remplacées ailleurs, mais voici celle qui a retenu mon attention et me fait m'arrêté un peu :

Citation:

---

Consommation en ressources d'une application JSF
L'exécution d'une application JSF est assez gourmande en ressource notamment mémoire à cause du mode de fonctionnement du cycle de traitement d'une page. Ce cycle de vie inclus la création en mémoire d'une arborescence des composants de la page utilisée lors des différentes étapes de traitements.

---

En fait l'application que nous voulons mettre sur pied est complex et très vaste. Cette faiblesse m'effraie un peu

Et puis il y a aussi celle-ci que je ne comprend pas bien
Le rendu des composants uniquement en HTML en standard
Dans l'implémentation de référence le rendu des composants est uniquement possible en HTML, alors que JSF intègre en système de rendu (Renderer) découplé des traitements des composants. Pour un rendu différent de HTML, il est nécessaire développer ces propres Renderers ou d'acquérir un système de rendu auprès de tiers.

Merci pour vos explications

Bonjour,

Chaque framework a ses défauts. Concernant les 2 points : je n'ai pas nécessairement constaté de problèmes importants de consommation de ressources mémoire sur ce point précis dans mon application, pourtant très complexe. Cela dit, il est important de designer les pages en visant une certaine simplicité, et d'éviter d'alourdir inutilement celles-ci.
L'un des points importants avec JSF, c'est que l'on ne contrôle que très peu le code HTML généré, à moins de créer soi même ses composants. Du coup, le poids des pages grossit généralement assez vite, et l'on a vite fait de dépasser des tailles relativement importantes (> à 100Ko). Certes aujourd'hui le haut-débit est presque partout, mais ce n'est pas une raison ;) C'est d'autant plus critique si l'on utilise beaucoup (et mal !) ajax dans son application...

Pour le second point. Si je comprends bien, il est dit que seul les générateurs de code HTML sont présents en standard. JSF est un framework orienté composants. Dans le cycle de vie, on va travailler avec ces composants, mais également avec des événements (à la manière de Swing). C'est lors de la dernière phase du cycle de vie de JSF (

Code:

---

RENDER_RESPONSE

---

) que l'on va générer le rendu final pour l'utilisateur. Théoriquement, il n'est pas obligé que ce rendu soit du HTML. Cela pourrait être du XML, du Flash, etc. Mais il faut reconnaitre que dans 99,9% des cas, c'est bien du HTML qui sera généré et c'est amplement suffisant. Donc à moins d'être dans un cas très particulier, je ne pense pas que ce soit là un gros problème.

Pour résumer : JSF n'est pas un mauvais framework, mais il faut juste être conscient de ses limitations et adapter le design des pages afin de limiter les risques d'impacts sur les performances...

ne vous braquez pas sur la consommation mémoire.

Tout d'abord, ce n'est pas l'arborescence de toutes les pages qui est gardée en mémoire, on garde seulement certaines arborescences dans le but d'éviter une surcharge au parsing.

Ensuite ce ne sont pas les objet Component qui sont conservé dans cette arborescence, mais uniquement leur état, obtenu via un appel à getState, restauré via un appel à setState. La pluspart des composant y mettront ce qui se trouve sur la balise correspondante, tout simplement. De plus, si c'est vraiment problématique pour vous, on peux toujours sauver l'état coté client et non pas coté serveur.

En ce qui concerne le HTML, seule le HTML est garantis en standard. Rien ne vous empeche de créer/acheter vos propres renderer (poru du WAP par exemple), il faudra juste reste conscient qu'il faudra en fournir pour tous vos composant, ça peut être fastidieux. Je me souviens qu'au début, oracle fournissait moyennant finance, des renderer qui s'affichaient le formulaire sur une console telnet. C'est dire la variété qu'on pouvait obtenir :)

Ok, je comprend, merci beaucoup