GWT + JSP, ce qui compte, c’est les valeurs !

Ça y est, depuis 6 mois que vous parlez de GWT à votre CP tous les matins, il veut bien vous laisser utiliser GWT au sein de la vieille webapp dont vous avez la charge. Mais quand même, faut pas pousser, on va pas faire du SPI et changer toute l’interface.

On a dépensé de l’argent à écrire toutes ces JSP, hors de question de les jeter! GWT, on va l’utiliser sous forme de petits widgets inclus dans les pages à droite à gauche, pour rendre certains cas d’utilisation plus fluide (ie, remplacer les workflows à 12 pages).

Ce qui se traduit par une petite incision dans notre bonne vieille JSP :

1
2
<script language="javascript" src="monModule/monModule.nocache.js"></script>
<div id="pointDAncrageDuWidget"></div>

Et une inclusion facile du widget en GWT :

1
RootPanel.get("pointDAncrageDuWidget").add(monWidget);

Jusque là, tout va bien. Sauf que patatra, la JSP a un contexte. Par exemple, la page que je vous êtes en train d’afficher représente un objet donné, et votre widget doit afficher des informations relatives à cet objet.

Comme l’application est totalement stateful (et que ça fait 5 ans que l’application est développée par des prestalimentaires), l’id de l’objet affiché n’est pas fourni en paramètre GET de l’URL, mais directement stocké en session. What ?! La session magique, c’est pas automatique!

Comment, dans votre widget GWT, accéder à des informations de contexte (quel objet ma JSP est-elle en train d’afficher ?). Je vous rappelle que le code GWT téléchargé est sans état, compilé une bonne fois pour toute en Javascript lors du build.

La réponse est on ne peut plus simple : en ajoutant un brin de Javascript à notre JSP, qui sera visible par notre widget GWT.

Il existe de multiple façons de faire, en voici une que je trouve intéressante : utiliser la classe Dictionnary.

Tout d’abord, on génère les valeurs qui vont bien dans notre JSP :

1
2
3
4
5
6
<script type="text/javascript">
var MonDico = {
  myObjectId: "<bean:write name="myObject" property="id" scope="session"/>",
  myObjectDescription: "<bean:write name="myObject" property="description" scope="session"/>"
};
</script>

Puis on fait hériter notre module GWT du module I18N pour pouvoir utiliser la classe Dictionnary :

1
<inherits name="com.google.gwt.i18n.I18N" />

Enfin on récupère les valeurs qui vont bien côté GWT :

1
2
3
Dictionary monDico = Dictionary.getDictionary("MonDico");
String myObjectId = monDico.get("myObjectId");
String myObjectDescription = monDico.get("myObjectDescription");
VN:R_U [1.9.22_1171]
Rating: 0 (from 0 votes)
Share

À propos de Pierre-Yves Ricau

Découvrez mon cv dynamique en ligne !
Ce contenu a été publié dans Non classé. Vous pouvez le mettre en favoris avec ce permalien.

5 réponses à GWT + JSP, ce qui compte, c’est les valeurs !

  1. Quand au titre, il fait référence… au jeu du sirop (c’est vendredi !) ;-)

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. mgrenonville@excilys.com dit :

    Attention toutefois, le Dictionnary est visible pour l’utilisateur dans le code source… Avec tous les risques que ça comporte, surtout si la-dite application qui stocke tout en session est sécurisé avec cette option structurante : “Une fois que l’id est mis en session, les droits en lecture ne sont plus vérifiés.”

    Personnellement, j’aurais plus utiliser les filtres JEE pour récupérer un certain nombre d’info depuis la session et les exposer via un ThreadLocal, par exemple.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  3. Tout à fait d’accord, le dictionnary est visible, mais au même titre que n’importe quelle information envoyée au client, que ce soit en RPC, en JSON, ou tout autre moyen.

    A priori, je ne comprend pas trop le lien avec les filtres JEE / la session / un ThreadLocal. Il s’agit ici d’exposer une information à utiliser côté client, du genre “je veux afficher le nom d’utilisateur dans le navigateur”.

    Évidemment, il est hors de question de faire confiance au client lorsque des appels au serveur sont fait, et je suppose que c’est le sens de ta remarque : ce n’est pas parce que le client dispose de l’information “username” qu’il faut l’envoyer lors d’appels Ajax subséquents. Il est effectivement préférable de garder ça côté serveur (par exemple en session), et effectivement dans ce cas là le ThreadLocal s’avère utile. Spring Security fonctionne ainsi…

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  4. mgrenonville@excilys.com dit :

    Je pensais plus à ton exemple, myObjectId: “” qui sous entend que tu mets l’id d’un objet. Tu parlais aussi d’un workflow de 10 pages, j’ai pensé qu’il s’agissait de l’id sur lequel tu faisais ce workflow.

    Pour le lien entre Session/ThreadLocal/ Filtre JEE, j’avais oublié que le RemoteServiceServlet exposait la request depuis un ThreadLocal. Dans le cas contraire, j’aurais utiliser un Filtre JEE pour mettre le dans un ThreadLocal et faire le même traitement.

    Finalement, le seul intérêt du Dictionnary est de ne pas avoir à envoyer une requête pour connaitre les informations du contexte. Mais finalement, est-ce bien raisonnable de ne pas faire cette requête ? Surtout quand on sait la confusion entre client et serveur, et quand on sait que certains envoient régulièrement des ids sans se poser la question de la sécurité derrière… J’aurais tendance à dire “non” :p

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  5. Ok, je comprend mieux :-)

    myObjectId provient d’un “code source existant tout vieux qui pue”, ce qui explique le stockage en session de l’objet… débile mais toute l’appli est faite ainsi.

    Et par ailleurs, moi je dis non à ton non ;-) . De manière générale, si une info de contexte peut-être donné le plus tôt possible (ie au moment du rendering JSP), il faut le faire. Cela évite de bloquer le chargement d’un widget parce qu’un appel RPC est nécessaire à l’init.

    Bon, ceci dit, je te rejoins sur la méfiance vers la méconnaissance des dévs, qui peuvent confondre client et serveur, surtout dans le domaine des RIA. Malheureusement, ça ne me paraît pas être un problème technique, mais plus un problème culturel / d’éducation.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)

Laisser un commentaire