Je reviens à la charge pour Publication externalize, finalement les problèmatiques auquel je vais me retrouver pose la question de ce dont on avait parler concernant l'amélioration du script engine, avec les applications à l'intérieur des pages wiki de base. Externalize on va packager les wikitty dans un jar, mais les sources dedans etc, devront toujours être considéré comme des wikitty ? Externalize on va compiler les sources et les packager, on package toujours en jar ? le code écrit en C par exemple que wikitty publication pourrait interpréter je le compile de la même façon ? et je met le résultat dans le jar, ou je le transforme en java à la volé pour le compiler dans le jar ? Dans le cas où les wikitty externalisés ne sont plus des wikitty je vois mal comment ils pourraient interagir avec les wikitty dit données, c'est là d'ailleurs que je pense rejoindre la problématique de wikitty publication. Et cette question reste ouverte:

...

...

...

Dans le mode externalize les jsp et autres resources peuvent être précompilées.

Pareil en fait, si le code est évalué par wikitty publication pourquoi le précompiler ? N'es ce pas le rôle de publication de lire le code et de l'interpréter à la volé ? un des buts de l'externalisation est la performance, si on ne fait que de l'interpretation, c plus long et moins sur (pas de check durant une phase de compilation) D'accord, admettons. En prenant ce schéma en exemple :

exemple architecture externalize

Des wikittyPub text ont été externalizé et sont donc dans wikitty externalize, le code effectif contenu dans ces wikitty pub text il doit être éxécuté par qui ?

Et en considérant que des wikittyPubText ont été "surchargé" en ayant été modifié et sauvegardé dans wikitty service comment ça se passe ? Pour la cohérence de l'éxécution tout devrais être fait au même endroit non ?

Une des motivations de publication c'est d'avoir un code "générique" fixé qui va s’exécuter avec des données différentes en fonction de l’appelant, enfin des données d'un wikitty service différentes. Si j'ai bien compris. Maintenant ça me parait pas si simple (ça serait pas un sujet de stage si ça l'était je suppose) il faudrait presque un nouveau type de wikitty pub qui contiendrais les sources compilées.

Manoël.

Normalement le plus gros du travail sur la partie externalize est terminée. J'ai dans un premier écrit la partie qui externalize vraiment, c'est à dire attaque le wikitty service sur file system et récupère tous les wikitty, pour ensuite décorer le code et le compiler, écrire les class et packager le tout en jar. Pour la décoration de code, j'ai écris une classe abstraite avec méthode abstraite eval qui prend juste en paramètre une map binding, et l'action d'évaluation si le wikitty est un wikittyPubTextCompiled on invoque la méthode eval de la classe en lui passant la map de binding. Je me suis servis du compile helper écrit pour isifish, j'ai repris la classe ZipUtil pour la transformer en JarUtil, ça fait la même chose, sauf qu'il y a une notion de fichier Manifest. Ensuite pour le wikitty service qui exploite un jar les fonctions de recherche et donc de vérification de contrainte sur un wikitty, j'ai pu réutilisé ce Jean avait fait pour les wikittyInMemory et que j'avais repris pour le service sur file system (ya une classe abstraite commune pour les deux services avec les fonctions de recherche dedans). Au niveau des propriétés je sauvegarde les Id, les version et les extensions, et avec ça je retrouve tout ce dont j'ai besoin pour reconstruire les wikitty. Du coup une bonne partie de ce qui devait être fait fonctionne. Il me semble que je devais faire quelque chose de plus sur wikitty publication ? Mais je me souviens plus exactement. Sinon bah le code est perfectible et il y a surement des choses à corriger. Manoël