Discussion :

[dwarlan]

Bonjour,

Je travaille sur l’IHM d’un projet. J’aimerais avoir des informations sur les bonnes pratiques au sein des JSP.
Il s’agit d’un projet struts avec l’utilisation des bibliothèques de tags html, bean et logic de struts.

Balises <html:html>, <bean:message … />, <bean:write … />

Est-il pertinent d’implémenter la JSTL et les EL au sein de ces pages et de chercher à les modifier en profondeur ? Quel serait le bénéfice ?

Je vous remercie par avance et n’hésitez à me demander des précisions.

Antoine

[OButterlin]

Il faut... non... mais si tu as besoin de conditionner des affichages en fonction de valeurs dans un bean, alors oui, c'est utile.

[Pill_S]

La bonne pratique, en général, c'est: pas de logique dans les jsp! même un pauvre "if" (déguisé via une taglib ou pas) c'est déjà pénible en terme de testing. Je ne parle même pas de debugging...

Une jsp devrait être utilisé en tant que moteur de rendu, c'est à dire, produire du html (en général...) à partir de données préparées à l'avance. ça ne doit pas devenir une sorte de container à tout faire. Je ne compte plus le nombre de projets sur lesquelles je suis passé qui ne respectaient pas cela, et qui devenaient une plaie en maintenance...

[OButterlin]

La bonne pratique, en général, c'est: pas de logique dans les jsp! même un pauvre "if" (déguisé via une taglib ou pas) c'est déjà pénible en terme de testing. Je ne parle même pas de debugging...

Je ne partage pas du tout ton avis, la logique liée à l'affichage de telle ou telle ressource en fonction de conditions DOIT être côté JSP.
Imagine le nombre de pages qu'il faudrait si on avait 10 blocs affichés en fonction de 10 paramètres différents cumulables, bonjour le truc

Une page ne doit pas avoir de logique de traitement, pour ça OK, mais par contre elle peut avoir une logique d'affichage... encore heureux...

D'ailleurs, si on regarde de plus près la logique JSF, l'attribut "rendered" est bien l'équivalent d'un <c:if> d'un point de vue du rendu.
Si on regarde d'encore plus près, même en JSF le <c:if> n'est pas à bannir complètement, la différence fondamentale entre <c:if> et "rendered" étant qu'avec un <c:if> le composant n'existe même pas côté serveur dans l'arbre de composants de la vue.

[Pill_S]

Bon en me relisant, je te l'accorde, j'y suis peut-être allé un peu fort... C'était pour donner l'idée générale

En tant que moteur de rendu, j'autoriserais les *petites* conditions logiques d'affichage mais il faut absolument (et là j'insiste ) que cela reste trèèès simple (suffisament pour ne pas nécessiter de tests): évaluer un booléen, voir deux dans une condition, qui soient affectés dans un autre couche.

Le risque étant de rapidement se trouver dans une situation impossible, où tellement de prise de décision est faite dans une couche quasi impossible à tester que l'on perd le contrôle de l'ensemble.

J'ai du maintenir des applis où l'on écrivait pratiquement le SQL dans la jsp. Et là, bonjour les dégats...

[OButterlin]

J'ai du maintenir des applis où l'on écrivait pratiquement le SQL dans la jsp. Et là, bonjour les dégats...

Oui, là on est dans la logique PHP des premières heures... tout ce qu'il faudrait éviter dans une application digne de ce nom...

En ce qui me concerne, j'irais même plus loin dans le nombre de tests effectués pour évaluer une condition d'affichage : 1 seul !
Pour ce qui est des applications JSF, mieux vaut passer par un ManagedBean pour évaluer plusieurs conditions et renvoyer un boolean que de cumuler les tests dans l'évaluation d'un rendered...
Exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<p:inputText value="#{monManagedBean.value} readonly=#{monManagedBean.isReadonly()}/>

plutôt que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<p:inputText value="#{monManagedBean.value} readonly=#{monManagedBean.updatable or monManagedBean.isUserInRole('USER') or ...}/>