On Thu, 14 Apr 2011 15:07:22 +0200 Manoël <manoel.fortun@gmail.com> wrote: ...
A ces objets wikitty on associe un wikittyLabel, c'est un objet qui peut contenir un ensemble de label différent, un label par exemple "src.org.chorem.entities" sert ici pour contenir le chemin menant au fichier sur le file system. Un wikitty peut avoir un certain nombre de label, pour les wikittyPub celà indiquera qu'ils appartiennent à plusieurs arborescences.
Bon, plus on avance et plus je vois de problème à l'utilisation de label :(. Par exemple si un PubText a 3 label, lorsqu'il arrive en FS, il n'aura plus que son Path et donc 1 label :(. Or les labels sont stockés dans le wikitty et non l'inverse. L'autre soucis, est si l'on appelle plusieurs PubText avec le meme nom (ils auront un id different mais vu qu'on les references tous avec leur nom, on ne pourra que difficilement avoir plusieurs applis sur le meme WS, il risque d'y avoir rapidement des objets avec les memes noms :( Si on prend une autre solution comme l'utilisation de TreeNode, on a plus le probleme de devoir conserver tous les labels d'un wikitty lorsqu'on le met en FS, car au contraire des Labels, les TreeNode on leur propre Wikitty et contiennent les Ids des Wikitties vers lequel il pointe. Mais pour le clash entre nom d'objet ca n'apporte rien. A moins de devoir donner le chemin complet a chaque fois ce qui serait penible :(. Et surtout on pourrait faire la même chose avec les labels. Mais il nous reste encore une solution :), les WikittyGroup. Qui permettent de rassembler des Wikitty, mais on une vie a eux (ils existent en propre au contraire des Label, et sont moins complexes a gérer/indexer que les TreeNode. Mais leur utilisation actuellement est plutot pour des Group de user, mais on doit pouvoir les reutiliser (a verifier) Faire le remplacement des Labels par des groups ne doit pas être trop dur, donc pour l'instant on change pas, pour que ca mûrisse et voir si on arrive pas a trouver une solution tout de meme avec les Labels, mais prévoir durant le codage que les Labels pourrait etre autre chose. Donc pour le clash de nom, la seul solution que je vois, est: - on met un nom simple, la recherche se fait dans le meme espace que le wikitty courant (donc dans le criteria de facon automatique on ajoute "AND label=xxxxx", ce qui serait moins facile si l'on utilise des groups :(, puisqu'il faudra faire une jointure et en wikitty ca fait 2 requetes) - on met un nom avec un path, la recherche se fait avec label + id (exemple de syntaxe: org.chorem.gepeto.ui#Home) D'ailleurs pour le problème de Label, peut-etre que lorsqu'on renvoi un PubText on ne synchronise que les info de cette extension et pas de l'extension label (on conserve toutes les autres extensions du Wikitty telle qu'elles sont). Par contre on ajoute toujours notre Label dans le champs des Labels (vu que c'est un Set, ca pose pas de probleme). Comme ca si une autre appli a supprimé ce PubText (suppression de son label), on ne le remettra pas, vu qu'on ne fait qu'ajouter le notre. ...
On conservera trace ausi dans ce même fichier de propriété du label courant, permettant de ne pas faire d'opération "complexes" et pénible sur les noms de fichier afin de retrouver le label de travail.
Je ne suis toujours pas d'accord avec ca. Pour moi on ne conserve pas le Label, on le reconstruit au besoin grace au Path sur le FS, car sinon on a une info conservée de deux façon différente et ce n'est jamais un bonne idée.
On distinguera deux fichiers de propriétés pour les informations un qui conservera
Pourquoi ne pas en faire qu'un seul ? id.UUID=fichier.txt version.fichier.txt=numVer checksum.fichier.txt=checksum Je prefaire prefixé par version et checksum que suffixé Apres je ne sais pas ce qui est mieux ce qui est au dessus ou id.fichier.txt=UUID version.UUID=numVer checksum.UUID=checksum Ca depend des demandes qu'on fait sur fichier. C'est peut-etre encore autre chsoe
meta.properties:
script.js.version=numéroVersion7 scripttut.js.version=numéroVersion image.png.version=numéroVersion current.label=racine script.js.checksum= checksum scripttut.js.checksum= checksum image.png.checksum= checksum
id.properties:
uubdazudba=image.png 11daz5facz=scripttut.js jbdub1dza8=script.js
...
Wikitty Service File System ---------------------------
Un tel service devra fournir les méthodes suivantes les méthodes de sauvegarde des wikitty, de restauration, ainsi qu'un certain nombre de fonctionnalités concernant les recherches de wikitty.
Ce service, ne gere que des WikittyPubXXX et lorsqu'on fait un find et qu'il detecte de nouveau fichier, il leur assigne un Id. ps: Il manque le pourquoi de cette nouvelle approche (completement universelle, peut servir pour faire de la syncrho entre 2 WS normaux, comme pour une synchro avec le FS pour les developpeurs). Pour les tests, on peut meme faire des tests avec les WS existant sans encore coder le WSFS. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com