Author: mfortun Date: 2011-06-16 17:24:34 +0200 (Thu, 16 Jun 2011) New Revision: 943 Url: http://nuiton.org/repositories/revision/wikitty/943 Log: * change externalize "solution" Modified: trunk/wikitty-publication/src/site/rst/wp-externalize.rst Modified: trunk/wikitty-publication/src/site/rst/wp-externalize.rst =================================================================== --- trunk/wikitty-publication/src/site/rst/wp-externalize.rst 2011-06-14 14:53:07 UTC (rev 942) +++ trunk/wikitty-publication/src/site/rst/wp-externalize.rst 2011-06-16 15:24:34 UTC (rev 943) @@ -17,28 +17,27 @@ compilé dans un jar, pour empêcher la modification. -Un wikitty service -++++++++++++++++++ +Lecture/écriture +++++++++++++++++ -La première analyse envisageait une jsp qui externaliserait les wikitty, mais -finalement je pense qu'une option intéressante serait d'utiliser une nouvelle -implémentation de wikitty service. +Ecriture +-------- -Ce service WikittyServiceExternalize implémenterait des méthodes comme le store -de list de wikitty, restore, et les méthodes de recherche. +L'écriture du jar et des wikitty compilé se fera par l'intermédiaire d'un +main java, qui pourra ensuite être étendu en plug in maven ou tâche ant. +Son role sera d'a partir d'un repos filesystem de wikitty, donc selon +le modèle de sauvegarde de wikittyPublicationFileSystem on compile les wikitty +et on les sauvegardes dans un jar en y joignant les sources des wikitty compilés. -Le store prendrait une liste de wikitty, les écrirais sur le disque comme le -wikitty service file system, compilerais ce qui est compilable et packagerais le -tout dans un jar. +Lecture +------- -Le restore et les recherches serait des méthodes qui exploreraient le jar. +La lecture de ce jar avec les wikitty sera à la charge d'un wikitty service qui +implémentera donc les méthodes de recherche et restauration de wikitty dans le +jar, il n'aura pas besoin des methodes de sauvegarde puisque le jar n'est +pas sensé être modifié. -Une autre solution serait que le stockage, précompilation, packaging se fassent -par une classe un peu similaire à l'outil de synchronisation de wikitty service -mais que les restores et méthodes de recherche se fassent par une implémentation -de wikitty service sur Jar. - Un nouveau type de wikittyPub +++++++++++++++++++++++++++++ @@ -46,26 +45,28 @@ encore des wikitty, ils ne peuvent plus être considéré comme des wikittyPubText, et on ne doit pas pouvoir les modifier. -Il faut un nouveau type de wikittyPub: -- wikittyPubCompiled -- WikittyPubStatic -- wikittyPubTextCompiled +Il faut une nouvelle extension de wikittyPubText wikittyPubTextCompiled. -Qui aurait en champ: -- nom -- mimetype (celà dit pas sur que ce soit nécessaire à la transformation du - wikitty en objet compilable celà sera peut être inséré dedans) -- content en byte +Qui aurait un champ qui contiendrait le byteCode java. +Cette extension serait utilisé en plus de l'extension wikittyPubText, évidement +puisque c'est une extension, mais celà signifie que dans le jar on aura les +source du wikitty, et donc à la restoration on pourra remplir le champ content +du wikittyPubText. + Conservation des propriétés des wikitty +++++++++++++++++++++++++++++++++++++++ Comme pour le stockage des wikitty sur file system dans wikitty publication, afin de pouvoir réutiliser les wikitty il faut pouvoir conserver certaines -propriété des wikitty, comme l'id, la version et eventuellement le mimeType. +propriété des wikitty, comme l'id et la version. +Dans le jar on sauvegardera donc les fichiers correspondant aux classes +compilés et les sources des wikitty ayant servit à la compilation, donc des +wikittyPubText. + Une solution serait comme pour les wikitty dans le file système de sauvegarde les propriétés dans des fichiers de propriétés. Mais dans le minimum possible, on aurait à la racine du jar dans un sous dossier externalIndex deux fichiers de @@ -98,9 +99,9 @@ ------------------------------------- id.properties: -11daz5facz=/label/unwikittyCompilé.class -jbdub1dza8=/label/unautre.class -dadzadzac=/label/chausette/autre.class +11daz5facz=/label/unwikittyCompilé.class # je ne sais pas si on stocke le chemin +jbdub1dza8=/label/unautre.class # direct vers le class ou le source +dadzadzac=/label/chausette/autre.class dcdzcve678=/label/chausette/fff.class oniifdefe4=/wi.jpg @@ -111,26 +112,22 @@ dadzadzac.version=3 dcdzcve678.version=1 oniifdefe4.version=1.2 -11daz5facz.mimeType=application/javascript -jbdub1dza8.mimeType=application/jruby -dadzadzac.mimeType=application/java -dcdzcve678.mimeType=application/javascript +Le mimeType et contenu pourrons être récupéré via le fichier source du wikitty +qui sera à coté du fichier compilé, normalement. -Es ce que finalement on ne pourrait pas négliger la version pour les -wikittyPubText externalizés? -Et considérer les wikitty comme tous de version 1.0 et donc ne plus avoir besoin -de sauvegarder dans un second fichier de propriété. -Dans le cas où l'on externalize des wikittyPubData on conserverait la version -ausi, bien que la question pourrait se poser aussi, puisque si ce wikitty -est déja existant dans le wikitty service appelant on pourrait considérer -que le wikitty externalizé est redéfini par celui du service. - - Mechanisme de transformation ++++++++++++++++++++++++++++ Le mechanisme de transformation d'un wikittyPubText en wikitty externalizé implique de décorer le code du wikittyPubText par du code java pour le compiler et le stocker sous forme de classe. + +Le mechanisme de décoration/compilation s'appliquera pour tout les langages, +pour ceux qui ne sont pas compilable, il sera chargé de décorer le script +avec les éléments (scriptEngine, etc) nécessaire à son interprétation, +et ce code proposera une méthode qui en entré à besoin des éléments de context +d'interprétation et renverra le résultat de l'exécution. + +