J’utilise le framework ZK (la démo qui vaut le coup d’oeil) depuis quelques mois pour construire une application web. La particularité de ce framework est qu’il dispose de nombreux composants graphiques attrayant pour l’oeil sans présenter de grosses difficultés coté développement : en effet, vous n’aurez pas de javascript à faire, tout se fait en Java pour la partie controlleur et gestion des évenements. La partie graphique utilise un langage descriptif proche du XML : ZUML.
La cohabitation avec Hibernate et Spring est plutôt bonne également.

Je suppose ici que vous êtes familier avec la classe GenericAutowireComposer et que vous avez déjà écris des pages zul.
Une difficulté s’est présentée lorsque l’on a voulu intégrer un objet flash. L’objet flash est présent au milieu d’autres composants ZK et lorsque l’utilisateur clique sur un bouton de l’application Flash, l’application (la page zul pour être plus précis)  doit récupérer les paramètres de l’objet flash pour mettre à jour certains composants de la page; tout ca sans recharger la page.
Idéalement, il faudrait que l’objet flash émette un évenement à destination du serveur comme si cet évenement venait d’un composant ZK. Ceci permettrait que l’évenement soit géré coté serveur comme n’importe quel élément, et qu’il soit traiter avec un handler déclaré dans un controlleur.
Aprés avoir ramer pour trouver une solution, voici comment j’ai finalement fais. C’est plutôt propre est trés bien intégré.

  1. On définit une méthode en Javascript dans la page qui prendra comme paramètres d’entrées les éléments de l’objet flash. Si on à 5 paramètres dans le flash, la méthode en JavaScript aura 5 paramètre
  2. Cet article explique comment depuis une application flash on peut appeler une méthode javascript présente sur la page : on modifie l’objet flash de sorte qu’il appelle la méthode définie en 1
  3. on utilise la méthode Javascript comm.sendUser(composant,param1,param2,param3, …) qui est fournie par ZK pour générer un évenement qui sera envoyé au serveur. Le problème réside dans la façon de nomer le composant …car ici on ne peut pas utiliser #{mainWindow.uuid}, ca ne marche pas car on se trouve dans du javascript !

Voici une méthode correctement écrite, qui suppose qu’un objet de type window possèdant un id « mainWindow » existe, et un controlleur qui étend GenericAutowireComposer :

<script type= »text/javascript »><![CDATA[
function maMethode(param1,param2,param3) {
comm.sendUser($e(« ${mainWindow.uuid} »),param1,param2,param3);
}
]]></script>

Explications :

  1. le premier paramètre de comm.sendUser doit être un composant ZK
  2. l’évenement envoyé au serveur est de type User
  3. le rendu de la page ZUL est effectuée par le serveur. Lors du rendu les références aux objets ZUL sont remplacées par leurs vrais noms
  4. la notation $e(« ${composantZK.uuid} ») permet de récupérer le composant ZK qui sera à l’origine de l’évement : lors du rendu cette notation sera remplacé par l’identifiant d’un vrai composant ZK. Ici le composant est mainWindow
  5. les autres paramètres seront disponibles cotés serveur dans le champ data de l’évenement

Côté serveur, le controlleur de mainWIndow doit disposer d’un handler pour traiter cet évenement et récupérer les paramètres. Voila comment cela se fait; en héritant de la classe GenericAutowireComposer c’est assez simple :

public class WindowController extends GenericAutowireComposer {// handler pour traiter l’evenement
public void onUser(Event event) {
String [] data = (String []) event.getData();
StringBuilder buf = new StringBuilder(« OnUser event : « );
if( data != null) {
for(int i=0; i < data.length; i++ ) {
buf.append(data[i]).append(« , »);
}
}
buf.setLength(buf.length()-1);
System.out.println(buf.toString());
}
}

On déclare la méthode onUser qui sera appelée sur réception par le controlleur d’un évenement de type User, comme celui envoyé par comm.sendUser(…).
Les paramètres passés à sendUser sont disponibles en faisant appel à getData() qui retourne un String [ ]. Reste ensuite à exploiter les paramètres.
Comme d’habitude, une fois qu’on a la réponse c’était finalement assez simple …

MAJ

, , ,

4 commentaires

  1. Super article sur ZK. On peut préciser qu’il s’agit de la version 3.6.x de ZK il me semble, même si a priori il devrait en être de même pour ZK 5.
    Au passage un pti plugin wordpress pour afficher la coloration syntaxique du code serait le bien venu 🙂

    • En effet, il s’agit d’une version 3.6.x de ZK. Je ne suis pas sur qu’elle soit toujours valide pour les nouvelles versions 5.0x, merci pour la remarque.

  2. Bonjour, je suis en train de migrer une application écrite en ZK 3.6 vers ZK 5 et l’object comm en javascript n’existe plus. Je galère comme un ouf pour trouver une solution.
    Quelques pistes ici : http://docs.zkoss.org/wiki/ZK/How-Tos/Concepts-and-Tricks#Pass_JavaScript_variable_value_to_ZK_Server

  3. Pour ceux que ça intéresse j’ai finalement réussi à faire à faire appel à une méthode java côté serveur depuis mon bout de javascript en passant les paramètres comme il faut.

    J’ai pour cela utilisé la nouvelle méthode de ZK 5 : zAu.send(new zk.Event(null, ‘onUser’, [param1, param2, param3])

    Cela appellera la méthode onUser côté serveur. Par contre attention grosse différence par rapport à ZK 3.6 : lors du passage des paramètres côté serveur ZK s’amuse à convertir automatiquement les types pour vous simplifier la vie mais cela peut être trompeur. Par exemple si vous passez 4 comme paramètre il créera un Integer mais si vous passez 4.5 il créera une String…

Répondre à wardiz Annuler la réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *