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. Les champs calculés =================== les champs calculés seraient ajoutés à la déclaration de l'extension. Il pourrait-être de plusieurs sortes: - request: on indique la requête à jouer pour remplir ce champs avant de retourner l'objet. (Probleme: comment faire avec le cache ? on rejoue ou non la requete, lorsqu'on redonne l'objet provenant du cache ?). Peut-être prévoir une méthode refresh sur le wikitty pour ces champs ? - readonly: les champs existent, mais en lecture seul pour l'utilisateur. les données sont produites et mises en place par un trigger qui les utilises. - java/onStore: les champs existent, mais en lecture seul, et sont remplis par l'appel de la classe Java associée au moment du store - java/onRestore: les champs existent, mais en lecture seul, et sont remplis par l'appel de la classe Java associée au moment du restore L'idée est que toutes ces types fonctionnent sur la partie api wikitty et non pas sur une implantation specifique (Solr, JDBC, ...) Voyez-vous d'autre type de fonctionnalité possible ? exemple:: Wikitty someobjects [0..*] javaOnStore=org.nuiton.wikitty.Compute Wikitty root readonly=true Wikitty parents [0..*] readonly=true Wikitty tree [0..*] request="TreeNode.name:('toto' OR 'titi')" Faut-il un tag explicite computed=true, ou seulement javaOnStore, request, ... suffisent ? Est-ce que request ne serait pas en fait un javaOnRestore qui aurait un argument qui serait la requête ? Wikitty tree [0..*] javaOnRestore="org.nuiton.wikitty.ComputedFieldRequest(\"TreeNode.name:('toto' OR 'titi')\")" ou Wikitty tree [0..*] javaOnRestore="org.nuiton.wikitty.ComputedFieldRequest javaParam="TreeNode.name:('toto' OR 'titi')" Les trigger/listeners ===================== Les listeners seraient prévenus lors du Store et du Delete. Il y aurait deux types de listener: - les listeners bloquants (qui travail avec le thread d'appel) - les listeners non bloquants qui utilise un thread distinct pour rendre la main rapidement. Pour ajouter l'un ou l'autre sur le WikittyServiceStorage, on utilise les mêmes méthodes, mais les listeners n'implantent pas la même interface. WikittyServiceListener et WikittyServiceThreadedListener. Ces listeners aurait accès au Service constituant le WikittyServiceStorage (storage et indexer). Mais il serai bon, qu'il travail avec l'interface de ces services et ne présume pas de l'implantation (ex: SolR). Il faudra donc potentiellement enrichir l'api pour cela. Par exemple si on souhaite mettre en Listener l'implantation de l'indexation des TreeNode, cela n'est pas vraiment possible actuellement, car trop proche de SolR (Peut-on vraiment faire autrement ?) Je ne pense pas qu'il faille étendre les listeners a tous les WikittyService. Car si l'on souhaite ajouter un traitement lors de l'appel du store sur le WikittyServiceCache, je pense qu'il est préférable de créer un nouveau type de WikittyService que l'on intercalera avant ou après le WikittyCache et on surcharge la méthode store. Ce mécanisme est celui utilisé actuellement pour implanter les fonctionnalités. La différence entre un champs calculé de type java/onStore et un trigger est que le trigger a vision sur tous les objets du store, alors que le champs calculé, ne connait pas les autres objets qui sont en train d'être storé en même temps que lui. De plus, il sont toujours bloquant. Les choses que l'on pourrait implanter avec ce mécanisme: - indexation des arbres - indexation des autorisations pour permettre un check plus rapide et plus simple des droits Vous avez d'autres idées ? Interrogation: je ne sais pas si les listeners non bloquants sont vraiment via (implantable) sans probleme insoluble -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com