On Mon, 7 Feb 2011 19:58:32 +0100 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Salut,
Je pense qu'il serait bon d'introduire la notion de tiggers et de champs calculés dans wikitty.
J'aime pas trop le terme trigger, ca fait un peu trop BD ;) Je prefere le terme listener sur le WikittyServiceStorage.
Au final, le terme Hook a ete choisi. Et l'implantation a ete faite d'une facon completement differente :). Le principe a été d'ajouter un nouveau WikittyServiceHook dans la pile des WikittyService. Ce WS surcharge toutes les méthodes de modification (store, delete, clear, ...). Un nouveau type WikittyHook a ete crée qui contient entre autre champs - un actionToHook qui indique sur quelle action on souhaite ajouter un hook - le hook en lui meme qui est un script (ex: js, groovy, ...) Le WSHook avant de faire l'action recherche tous les WikkityHook qui portent sur cette action prefixe de 'pre' ex: pre-store. Et les execute. La meme chose est fait apres l'action avec par exemple post-store. Le script a acces au WikittyHook qui le contient, au WS sous-jacent, au argument de la methode (qu'il peut modifier s'il le souhaite), au resultat de la methode s'il s'agit d'un WikittyEvent. Cette implantation permet de mettre en place des champs calcule ou des triggers. Bien sur si une application oublie de stocker les WikittyHook ou de mettre dans la pile de WS le WikittyServiceHook, rien ne se passera :) L'implantation de ce mecanisme a ete simple et est non intrusif. Par contre c'est pas encore testé :). Donc voyez vous des choses qui pourrait coincer ? ou des choses auquel j'aurais pas pensé ?
Les champs calculés =================== ... Faut-il un tag explicite computed=true
Le hook, peut modifier n'importe qu'elle champs d'un objet qui est en train d'être stocké. Mais peut-etre est-ce tout de meme bien que ces champs soient marqués pour par exemple pour interdire leur modification en dehors du WikittyServiceHook (je ne sais pas encore comment faire) ou tout simplement pour qu'on sache que c'est un champs calculé. exemple d'implantation d'un "pre-store": // On met a jour la date d'un extension pour tous les wikitties qui ont // cette extension for w in wikitties: if LastModifiedTimeHelper.hasExtension(w): LastModifiedTimeHelper.setDate(w, new Date()) ...
Les trigger/listeners ===================== ... - les listeners bloquants (qui travail avec le thread d'appel) - les listeners non bloquants qui utilise un thread distinct pour rendre la main rapidement.
Toutes les executions de Hook sont bloquante. Si un Hook souhaite etre non bloquant cela reste a sa charge ex: new Thread() { // ecriture de du code a executer }.start(); Dans ce cas, il ne doit pas chercher a modifier les arguments de la methode ...
Les choses que l'on pourrait implanter avec ce mécanisme: - indexation des arbres
Je ne suis pas sur qu'on puisse avec cette implantation faire cela
- indexation des autorisations pour permettre un check plus rapide et plus simple des droits
Par contre, on peut tres bien imaginer un Hook qui cree toutes les bonnes permission pour les nouveaux objets, ou qui fait d'autres travaux lors de la creation d'une personne, l'ajout d'une personne a un group, la sauvegarde d'une securite, ... -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com