Ce petit billet pour vous expliquer comment passer des paramètres à un assembleur hibernate. Il existe deux manières de faire : les paramètres ordrés et les paramètres nommés.

Prenons un exemple pour illustrer mes explications. Dans ma base de données se trouve une table "enfant" qui répertorie le nom des enfants appartenant un deux "parents", lesquels sont eux mêmes liés à un "couple". Le tout forme une "famille". Un enfant possède donc son identifiant propre, ainsi que 2 identifiants représentant ses parents.

J'ai un assembleur hibernate qui me permet de récupérer tous les enfants (ChildrenVO) d'un parent dont je dois passer l'identifiant. Soit je passe l'identifiant du père, soit celui de la mère.
Mon assembleur possède une requête du type :

<query name="all.children">From ChildrenVO where fatherid=x or motherid=x</query>

Seulement, comment passer des paramètres à mon assembleur ?? La méthode fill du dataService permet de passer une suite de paramètres :

var ds:DataService = new DataService();
ds.fill( "myDestination", myParam1, myParam2, ... );

Mais ça ne me dit toujours pas comment récupérer ces paramètres dans mon assembleur hibernate. En fait, la documentation sur LCDS contient quelques paragraphes à ce sujet :

Il est possible de passer :

• soit un tableau (Array) du type [12, 12] avec une requête du type "From ChildrenVO where fatherid=? or motherid=?"
• soit un objet (Object) du type {fatherid:12, motherid:12} avec une requête du type "From ChildrenVO where fatherid=:fatherid or motherid=:motherid"
• soit, dans ce cas précis, un objet (Object) du type {id:12} avec une requête du type "From ChildrenVO where fatherid=:id or motherid=:id" (puisque les 2 valeurs sont les mêmes)

Ainsi, il est possible de passer des paramètres à un assembleur hibernate, afin de rendre plus dynamique les retours de données.

La phase suivante, que je n'ai pas encore réellement abordée mais qui me pose passablement de problème, est de savoir comment stocker côté serveur les variables identifiantes d'un utilisateur loggé et de les réutiliser dans les assembleurs hibernate. Car il n'est pas concevable de passer depuis le client tous les identifiants "sensibles" d'accès aux données propres à l'utilisateur. Le swf n'étant pas un format surprotégé mais plutôt relativement facilement décompilable, un petit malin aurait tôt fait de pouvoir passer n'importe quelle valeur d'identifiant "sensible" et ainsi accéder à des données ne lui appartenant pas.

Le prochain challenge est déjà en route