Discussion :

[loudo]

Bonjour,

J'utilise gwt avec google app engine. J'ai une question concernant les échanges entre le client et le serveur en mode RPC avec GWT.


Voici un exemple de bean que je compte échanger entre le client et le serveur. Si j'ai bien compris le bean doit être entièrement serializable.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Lieu implements Serializable {
  // Données
  public String a;
  public String b;
 
  // Méthodes
  public void methodes1() {
  }
 
  public void methodes1() {
  }
 
}

Ce que je cherche à comprendre c'est si le code des méthodes existe réellement sur le client en javascript ou si lors de l'appel d'une méthode sur le client un appel ajax est effectué. En fait je me pose cette question pour éviter de stocker du code fonctionnel sur le client en javascript. Merci de votre aide.

[benwit]

Si ton bean est dans ta partie cliente, il sera traduit en javascript par le compilateur GWT (un "bean" javascript avec propriétés et méthodes).
Tu pourras donc t'en servir dans ta partie cliente et tu pourras l'envoyer au serveur par le mécanisme de sérialisation RPC.

Ce bean compilé cette fois-ci par le compilateur Java pourra être également utilisé côté serveur comme tout bean Java.

Jusque là, c'est bon.
Où cela se complique, c'est au niveau de la persistance de ce bean côté serveur. Si on utilise JPA (via l'implémentation Hibernate, DataNucleus) ou JDO (DataNucleus, ...), il semblerait qu'on ne puisse plus dès lors le sérialiser en Javascript et donc, il ne peut plus faire partie du client ...

Cela, c'est d'après ce que j'ai lu car du coup, je n'ai pas essayé.
J'imagine que dans les deux cas (JPA/JDO), les annotations dans le source sont gênantes pour le compliateur GWT ? Mais on pourrait imaginer des "Mocked Annotation GWT compatible" (Est-ce que quelqu'un a essayé ?) ou alors de se passer des annotations et utiliser des fichiers de config xml à la place.

Le hic avec les implémentations JPA comme Hibernate, c'est que si j'ai bien compris, il n'utilise pas ton bean directement et c'est pour cela que ce n'est pas sérializable en Javascript. (Il utilise le pattern proxy pour une histoire de lazy loading sinon si tous tes objets sont liés entre eux, il te remonterait la base en mémoire et aussi pour pouvoir ajouter du code supplémentaire pour la persistance)

Avec JDO, l'ajout de ce code supplémentaire (pour la persistance) se fait par enrichissement du byte code (enhancement). En écrivant ceci, si on n'utilise pas par les annotations, je ne vois plus ce qui pourrait gêner ? Le compilateur GWT travaillant uniquement sur le source, il doit se moquer du .class enhancé (à moins que ça ne le gène pour le hosted mode ?)

Bref, ce n'est pas simple ...

Si ton bean est dans ta partie serveur, tu pourras utiliser les annotations JPA ou JDO pour le faire persister via DataNucleus dans BigTable de GAE. Mais du coup, il ne peux plus voyager vers le client par le mode RPC.
L'échange des données peut se faire via JSON/XML et alors, il y aura des requêtes Ajax.
Si tu veux utiliser quand même RPC, certains utilisent un objet côté client qui correspond à l'objet côté serveur. Exemple :

package client :
LieuModel (simple bean avec propriétés et méthode "GWT compatible")

package server :
Lieu (bean identique où en revanche tu fais du full Java (pardon, du java GAE compatible)) et des méthodes de conversion :
LieuModel entityToModel(Lieu lieu)
Lieu modelToEntity(LieuModel lieuModel)

Personnellement, je pense aussi que le code métier devrait rester sur le serveur et juste envoyer au client des objets de données pour l'affichage.
Cela nécessite des appels Ajax.