Le 07/02/2011 19:58, Benjamin POUSSIN a écrit :
J'aime pas trop le terme trigger, ca fait un peu trop BD ;)
J'ai pas vu la référence. Moi ça me fait plutot penser à de l'électronique mais bon on va pas chipoter :D.
Les champs calculés ===================
Faut-il un tag explicite computed=true, ou seulement javaOnStore, request, ... suffisent ?
je pense qu'ils doivent suffire.
Est-ce que request ne serait pas en fait un javaOnRestore qui aurait un argument qui serait la requête ?
Ca me semble mieux, ça enlève un truc de plus à connaitre pour maîtriser le tout.
Les trigger/listeners =====================
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.
Ok, parce que jusque là pour moi c'était le même chose...
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 ?
Oui, pour des trucs métiers dans des applis qui utilisent wikitty ;) Globalement j'ai envie de dire cool, ça risque de simplifier pas mal certains bouts de code et va permettre d'imaginer de nouvelles choses/utilisations. Et permettre d'être plus souple. Par contre, il faut faire attention à ce que que ça reste bien 'déconnectable' simplement pour que l'utilisateur lambda qui n'en a pas besoin ne se retrouve pas noyé dans une usine à gaz. Wikitty, à la base, doit servir à masquer à l'utilisateur la complexité de la problématique des modèles volatiles et facilement changeables. Si on fait un framework super compliqué, on a perdu ;). My 2 cents. Jean