December 2010 - Wikitty-devel - mailman.cloud.codelutin.com

[fixed] Anomalie #1182: WikittyException when copying a wikitty with a lower bound > 0
by Benjamin POUSSIN 30 Dec '10

30 Dec '10

Salut, Jean, j'ai normalement fixé le problème, mais je ne peux pas tester facilement (wikitty est en chantier sur ma machine et je manque de temps/courage, et comme ca si ca marche pas je te le laisse en exercice ;)) donc si tu pouvais recuperer le commit et tester merci -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

2 1

[ANN] - Wikitty 3.0.1 released
by nuiton.org Release Notification 24 Dec '10

24 Dec '10

1 0

[ANN] - Wikitty 3.0 released
by nuiton.org Release Notification 23 Dec '10

23 Dec '10

1 0

semantique des methodes findNodeCount et findAllChildrenCount
by Benjamin POUSSIN 21 Dec '10

21 Dec '10

Salut, Les methodes: * public Integer findNodeCount(WikittyTransaction transaction, Wikitty w, Criteria filter) * public Map<String, Integer> findAllChildrenCount( WikittyTransaction transaction, Wikitty w, Criteria filter) Prenne un critère en parametre, mais quel est la semantique de ce critere ? Y'a rien dans la javadoc. Donc soit: 1) le critere est sur les noeuds a retourner (nom ou attachment present) 2) le critere est sur les attachments pour savoir quelle noeud retourne Je serais tenté de dire le 2ème car il permet de faire pratiquement la même chose que le 1 sauf pour la recherche sur le nom du noeud. Et un cas métier serait par exemple la présentation d'une page d'option ou les options sont dans un arbre (ex: eclipse) avec une zone de critère en haut de l'arbre pour n'afficher que les noeuds contenants des attachments qui satisfont le critère demandé. Sauf qu'en wikitty un TreeNode peut avoir en même temps d'autres extensions. Et dans ce cas, pouvoir faire des filtres directement sur les noeuds via un critère serait utile. Donc quelle sémantique pour les méthodes actuelles ? faut-il prévoir deux critère dans les signatures des méthodes ? prévoir d'autres méthodes ? -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

4 3

Problème dans l'indexation de treenode dans wikitty
by Benjamin POUSSIN 21 Dec '10

21 Dec '10

Salut, En refactorant l'indexation pour comprendre comment tout ça fonctionnait, je me suis aperçu (à moins que je ne me trompe) que ce n'était pas vraiment optimal comme façon de faire. Concept ======= On a des TreeNode avec un 'parent' qui donne la structure de l'arbre. Chaque TreeNode peut avoir des attachments qui sont des objets attachés à un noeud. On veut pouvoir retourner le nombre d'attachments à partir d'un noeud qui satisfassent un critère (1 level ou tous les sous fils). Ce nombre d'attachments représente le nombre d'attachment du TreeNode demandé mais aussi tous ses fils. Actuellement ============ Lors du store d'un objet s'il fait parti des attachments d'un TreeNode on lui ajoute plusieurs champs - tree.parentId = childId (N fois pour representer tout le chemin juste qu'au root) (pour le TreeNode contenant cet attachment on met comme childId le marqueur 'empty') - tree.root= rootId Cela permet de faire des recherches sur les objets en facetisant facilement sur le fait qu'il soit dans un arbre ou non. Les problèmes sont: - on multiplie le nombre de champs de facon important dans solr (Si l'attachment est dans 3 arbres a une hauteur de 6 on crée ~18 nouveaux champs solr (je ne sais pas comment solr se comporte avec beaucoup de champs à indexer) - qu'il est coûteux de faire ainsi lorsque l'arbre a beaucoup d'attachment. Dès qu'on change un TreeNode, il faut ré-indexer tous les attachments de ce TreeNode mais aussi de ses enfants. (injouable par exemple sur jurismarches après quelques années d'utilisations avec plusieurs milliers d'attachments par noeud). Proposition =========== Ce que je propose est de modifier la façon d'indexer les arbres pour que ce soit les TreeNode eux même qui aient des informations complémentaires et non pas leurs attachments. On ajoute donc à chaque TreeNode: - tree.parents = liste de tous les parents (champs multi-value) - tree.root = rootId Un noeud et ces fils ne sont ré-indexés que si le champs 'TreeNode.parent' est marqué dirty ou qu'il est null (création d'un nouvel arbre) exemple: root->n1->n2->n3 root: * treenode.parent=null * #tree.root=rootid * #tree.parents=rootid n1: • treenode.parent=rootid • #tree.root=rootid • #tree.parents=n1id,rootid n2: • treenode.parent=n1id • #tree.root=rootid • #tree.parents=n2id,n1id,rootid n3: • treenode.parent=n2id • #tree.root=rootid • #tree.parent=n3id,n2id,n1id,rootid Ce que cela change ================== Cela ne permet plus de faire des recherches sur les attachment facetisé sur TreeNode, mais il y a peut-etre d'autre moyen de faire (actuellement cela ne semble pas utilisé) Ré-indexation ------------- Fréquence: dépend de l'application et de la fréquence de la modification des arbres (potentiellement élévé, ne doit pas être coûteuse) si field dirty contient 'parent' ou est null on reindex ce noeud et tous les noeuds trouvé par la requete query(tree.parents=nodeId) actuellement: N requêtes, N store. Avec N = nombre d'attachment nouveau: total 1 requêtes + M store. Avec M = nombre de noeud fils Recherche du nombre d'attachment pour un noeud et ses fils ---------------------------------------------------------- Fréquence: dépend de l'application, mais souvent élevé (affichage d'arbre avec le nombre entre parenthèse) si on souhaite connaitre le nombre d'attachment d'un noeud (avec les sous noeuds) on fait la recherche (tree.parents=nodeId) on boucle sur les resutats pour additionner les attachments de chaque noeud (total 1 requete) (actuellement 2 requetes) Recherche des attachments suivant un critère -------------------------------------------- Fréquence: dépend de l'application, mais normalement rare Si on souhaite recherche les attachment suivant un critère a partir d'un noeud, on fait la recherche (tree.parents=nodeId) on concatene tous les ids de tous les attachment des noeuds trouves. Puis on relance une recherche (critère demandé) où l'on a ajouté une condition pour que les documents retournés doivent être dans la liste des id des attachments précédemment construite. (total 2 requêtes) (acutellement 1) Question ======== - voyez vous des problèmes dans la nouvelle proposition - supprime-t-on l'ancien indexer par le nouveau ou laisse-t-on les deux a disposition ? -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

3 2

vers 1 seule methode a pouvoir charger des wikitties sur le WikittyService
by Benjamin POUSSIN 20 Dec '10

20 Dec '10

Salut, Actuellement sur le WikittyService, il y a bien sur la methode restore qui permet de recupere un wikitty, mais aussi public Wikitty findByCriteria public Map<WikittyTreeNode, Integer> restoreChildren public Entry<WikittyTreeNode, Integer> restoreNode je propose que ces methodes ne retourne plus directement des Wikitty ou WikittyTreeNode sur le WikittyService mais seulement des Ids. Par contre le Proxy lui retourne bien des Objets. Donc pour le developpeur c'est transparent. L'avantage toutes les restorations sont centralisees sur une methode et donc c'est beaucoup plus simple pour gere le cache. Les methodes find retourne des ids et donc n'utilise que le SearchEngine et si l'objet est deja dans le cache le WikittyStorage et WikittyExtensionStorage ne sont pas du tout solicite. Dans le cas on l'on arrive a distribuer le SearchEngine cela apporte beaucoup. Et meme si on ne distribue pas le SearchEngine et que l'on utilise le cache cela devrait permettre de meilleurs performance pour les appli client/serveur (si le cache est bien dimensionne :)). Pour les applis standalone cela ne changera rien au pire et ameliorera les choses au mieux Il y a aussi la methode public WikittyTree restoreTree Je propose quelle disparaise du WikittyService et ne soit que sur le proxy l'implantation serait je pense facile avec les methodes existantes // recherche de tous les noeuds a partir de 'wikittyId' List<TreeNode> all = findallbyCriteria(TreeNode.class, Criteria("#tree.parents:wikittyId)); // et reconstruction de l'arbre avec 'all' Si pas d'objection, je vais modifier cela d'ici peu -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

2 1

Probleme d'indexation: impossible de forcer un champs en lowercase
by Benjamin POUSSIN 19 Dec '10

19 Dec '10

Salut, Impossible de comprendre pourquoi ca ne marche pass :(. Si quelqu'un a une idee ? J'ai ca dans le schema.xml <fieldType name="string_lc" class="solr.StrField" sortMissingLast="true"> <analyzer>  <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.LowerCaseFilterFactory"/> </analyzer> </fieldType> Et les champs finissant par _s_c qui l'utilise. Donc je m'attend a ce que lors de l'indexation ces champs finissent en lowercase. Maleureusement, lorsque je regarde avec luke les mots sont toujours avec des majuscules et surtout la recherche si on ne respecte pas la case échoue :(. J'ai aussi essayer avec le LowerCaseTokenizerFactory ca ne change rien :(. Pourtout le code des ces deux classes font bien des .toLowerCase sur les chaines et sont loader car si je fais une faute de frappe sur leur nom de classe, j'ai une exception qui s'affiche. Si quelqu'un a le moindre soupçon d'idée, je suis preneur. Sinon je vais faire du pas a pas dans le code Solr/Lucene :( pour essayer de comprendre par ou ca passe. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

1 0

Nouvelle implantation du cache et amelioration de l'existant
by Benjamin POUSSIN 19 Dec '10

19 Dec '10

Salut, Le cache Wikitty a été améliorer. Le service est maintenant configurable pour y mettre n'importe quelle implantation via configuration. Il y a actuellemnt deux implantations: - WikittyCacheSimple (du fait maison) - WikittyCacheJCS (qui utilise apache JCS) Configuration ============= wikitty.WikittyServiceCached.components=org.nuiton.wikitty.services.WikittyCache(Simple|JCS) WikittyCacheSimple ------------------ # Liste des extensions à conserver le plus possible, dans cette # implantation on utilise des HARD références (tout toujours conservé) wikitty.service.cache.priority.extensions="" # le type de référence à utiliser pour les autres objets (soft ou hard) wikitty.service.cache.simple.reference.type=soft WikittyCacheJCS --------------- On utilise 3 regions: priority, wikitty, extension Par defaut il n'y a pas de stockage sur disque # Liste des extensions a conserver le plus possible, dans cette # implantation on utilise une région specifique ("priority") wikitty.service.cache.priority.extensions="" # nom des auxiliaires a utiliser (aucun par defaut) jcs.default= # nombre maximum d'objet par region jcs.default.cacheattributes.MaxObjects=1000 Pour le reste ce cache se configure comme JCS se configure donc voir la doc de configuration JCS pour plus d'option http://jakarta.apache.org/jcs/RegionProperties.html -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

1 0

Clash de nom de champs dans l'indexation SolR
by Benjamin POUSSIN 16 Dec '10

16 Dec '10

Salut, Actuellement pour un wikitty on stocke dans SolR les champs du wikitty plus quelques info complémentataire pour optimiser les recherches. Actuellement ============ - id: [id] du wikitty - text: concatenation de tous les champs pour une recherche fulltext - WikittyTreeNode.root = [rootId] - WikittyTreeNode.[nodeId] = [parentId] - all.[fieldname] = [valeur] pour pouvoir recherche un champs sur toutes les extensions (exemple le champs name de toutes les extensions du wikitty) - [extName].[fieldName] = [valeur] Le problème est que les champs ajouté ne sont pas différenciable des champs du wikitty. Qu'arrive-t-il si quelqu'un créer une extension 'all' ? qu'arrive-t-il si quelqu'un modifie WikittyTreeNode pour lui ajouter le champs 'root' ? Plus rien de fonctionne :( L'idée est donc de préfixer tous les champs spécifique par un '#'. Et comme le pattern d'une extension doit-être [_A-Za-z]. Il ne peut pas y avoir de clash A venir ======= - #id: [id] du wikitty - #fulltext: concatenation de tous les champs pour une recherche fulltext - #tree.root = [rootId] - #tree.[nodeId] = [parentId] - #all.[fieldname] = [valeur] pour pouvoir recherche un champs sur toutes les extensions (exemple le champs name de toutes les extensions du wikitty) - [extName].[fieldName] = [valeur] Impact ====== Il faut lancer une ré-indexation de toutes les données avant de déployer les nouvelles versions wikitty qui utiliserait ce nouveau nomage. Donc plus tôt on le fait moins d'impact il y a. Question ======== Quelqu'un voit-il un problème avec ce nouveau système ? -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

2 1

module de publication (analyse)
by Benjamin POUSSIN 13 Dec '10

13 Dec '10

Salut, Voila l'analyse pour le module de publication wikitty, a vos remarques :) Un poc a été commencé vite fait pour vérifier la faisabilité (mais c loin d'être fini/utilisable :)) http://svn.nuiton.org/svn/wikitty/trunk/wikitty-publication/src/site/rst/wp… =================== wikitty-publication =================== But === Le but de la publication est de pouvoir créer des sites web en stockant les informations nécessaires directement dans wikitty. Contraintes =========== La publication doit répondre à plusieurs contraintes: * stockage dans wikitty * développement en équipe aisé avec les outils habituels (éditeur, svn, maven, ...) * gestion de l'authentification et des autorisations * multi-langue * multi-context (utilisation de plusieurs WikittyService par la même instance de publication) * permettre le développement d'applications * déplacement aisé d'applications d'un WikittyService vers un autre (partage d'application) * mise en production d'applications ainsi créées hors de wikitty pour des besoins spécifiques Les actions =========== L'idée général est d'avoir quelques actions de base mappées sur un path (ex: /view/ -> action view) Devant cette action on détermine sur quel context on fait l'action (WikittyService). Le reste de l'url sont des arguments pour l'action. Les actions de base sont: * ''login'' pour permettre de s'authentifier * ''view'' pour permettre de recherche des wikitties d'afficher la liste des resultats et d'en voir un en détail * search * vue list/détail * ''edit'' permet de créer, ajouter des extensions à un wikitty, modifier les valeurs des champs, supprimer un objet * create * modif * delete * ''raw'' permet de retourner la valeur d'un champs d'un wikitty dans un typemime précis * ''eval'' permet d'évaluer un WikittyPubText * ''admin'' Analyse et admin du WikittyService * import * export * synchro depuis un autre WikittyService (affichage des couples WikittyPub???/Label dispo pour ensuite synchroniser une application) * proxy stat * admin extension Pour cela on défini deux objets de publication: * WikittyPubText: pour les contenus textuels * name: String unique=true notNull=true * content: String multiline=true * mimetype: String * WikittyPubData: pour les contenues binaires * name: String unique=true notNull=true * content: Binary * mimetype: String Ensuite grâce à ces actions de bases on peut construire des applications complètement contenu dans le WikittyService (code, template, données) Format des URL ============== la syntaxe complète d'une url est:: /[context]/[action]/[mandatory_args]?[args key=value] * ''context'' est le context pour trouver le bon WikittyService * ''action'' est le nom de l'action à effectuer, la classe gérant cette action est trouvée dans le fichier de configuration * ''mandatory_args'' sont des arguments obligatoires pour l'action * ''args'' sont des arguments optionels pour l'action sout forme de paramètre de requête Context ======= Lorsque la demande HTTP arrive sur le server un WikittyPublicationContext est créé pour conservé le context de la demande. Ce context permet de récupérer un WikittyProxy pointant sur le bon WikittyService. Pour cela le fichier par defaut Wikitty est lu, la variable wikitty.data.directory est surchargée pour lui ajouter le context de l'url (pour différencier les espaces de stockage des différents context). Ensuite s'il existe un fichier spécifique de configuration de wikitty pour ce context il est lu pour permettre la surcharge de configuration spécifiquement pour un context. Les fichiers de configuration spécifique sont trouvé grâce au pattern de fichier trouvé dans la configuration de wikitty-publication. Recherche des actions ===================== L'action est retrouvée grâce au fichier de configuration de wikitty-publication. On indique dans le fichier la classe héritant de WikittyPublicationAction permettant de gérer l'action demandée. Amélioration des URLs ===================== Par défaut les actions recherchent ''WikittyPubText.name et WikittyPubData.name s'il n'y a pas de = dans l'argument obligatoire.'' Par exemple les URLs suivantes sont équivalentes:: /eval/WikittyPubText.name=Wiki /eval/Wiki /raw/WikittyPubText.name=WikiLogo /raw/WikiLogo Action eval =========== Eval permet d'évaluer un WikittyPubText en fonction de son typemime, pour cela on utilise l'api javax.script. Plus il y a d'engine disponible plus il y aura de langage supporté. Par défaut seul le javascript (Rhino) est présent dans le JDK. Automatiquement on a accès dans les scripts aux variables: * ''WPContext'' qui est le context de publication * ''nextUrl'' est en fait la concatenation des arguments obligatoires moins la page actuellement evaluée. ex: /eval/Wiki/AutrePage/EtEncore => /AutrePage/EtEncore Action Login ============ Cette action si elle n'a pas d'argument affiche un formulaire pour demander un login et un password. Si l'action à les arguments login et password alors elle authentifie et crée le cookie nécessaire. En cas d'échec ou de succès si dans les arguments on retrouve les actions à faire on les faits sinon on affiche simplement le résultat. exemple d'url d'authentification:: /login?login=moi&password=xxxx&succes=/eval/Wiki/WikiHello&error=/eval/WikiBadLogin Si on a l'argument logout de présent dans les paramètres alors un logout est forcé. Par défaut si on demande un login et que l'utilisateur était déjà loggué alors un logout est aussi fait avant la nouvelle authentification. exemple d'url de logout forcé:: /login?logout&succes=/eval/Wiki/WikiHello Authentification ================ Une fois loggué le token est conservé dans un cookie pour permettre d'être authentifier pour plusieurs contexts (WikittyService) distinct en même temps. Développement d'application ============================ Le but est de pouvoir facilement développer des applications avec ces outils abituels (editor, svn, ...). Pour cela on utilise l'application d'extraction de WikittyPubText et WikittyPubData. Cette application permet de récupérer l'ensemble de ces types d'objet en fonction d'un Label qu'ils ont. Il faut donc que l'ensemble de ces objets pour une application donnée est un Label en commun. Si on a le WikittyPubText(''"Wiki", "<h1><%=...", "text/jsp"'') avec le Label ''org.chorem'' il deviendra sur le système de fichier /org/chorem/Wiki.jsp avec comme contenu le content du WikittyPubText. On procède de la même manière pour les WikittyPubData. L'application a un module de mapping entre le type mime et l'extension des fichiers. Les Labels recherchés sont récursif si besoin. Par exemple ''org.chorem.bonzoms'' est un sous Label de ''org.chorem. ''Si l'on demande donc la récupération des WikittyPubText en récursif de ''org.chorem ''on récupérera aussi les WikittyPubText qui ont le Label ''org.chorem.bonzoms ''ou'' org.chorem.gepeto''. L'application de synchronisation est capable de récupérer (checkout) mais aussi de pousser (commit) les modifications. Lors du commit il est possible de pousser les modifications vers un autre context que le context initial. Par exemple si l'on récupère les fichiers depuis le context 'chorem' on peut repousser les fichiers dans le context 'chorem-test' et ainsi facilement faire des tests avant de pousser en production les changements. Il est ainsi possible de mettre les fichiers dans un svn classique si on le souhaite. commande de l'application de synchronisation: * ''checkout [--recursion (true|false)] [url du WikittyService] [Label à extraire] [directory local d'accueil]'' * ''update [--recursion (true|false)] [--ws (url du WikittyService)] [répertoire à mettre à jour]'' * ''commit [--recursion (true|false)] [--ws (url du WikittyService)] [répertoire à pousser]'' * ''delete [--ws (url du WikittyService)] [répertoire ou fichier à supprimer]'' * ''relocate [nouvelle url du WikittyService par defaut] [directory a relocaliser]'' Il n'y a pas de add, tous les fichiers sont automatiquement commités. L'action relocate recherche le fichier ''.wikitty-publication/source'' pour le modifier Lors du checkout un fichier .wikitty-publication-sync/source est créé dans le répertoire root du chekout contenant l'url source des fichiers et le label extrait. Si lors d'un commit ou delete l'url n'est pas indiqué, alors cette url sera utilisée par défaut. Dans chaque répertoire de l'application lors du ''checkout/update/commit'' la wikitty version de chaque fichier présent est mis dans le fichier .wikitty-publication/versions. Ce fichier est sous la forme d'un fichier de propriété avec en cle le nom du fichier/wikitty et valeur la version. Cela permet de ne pas autoriser le commit si des modifications ont été faite sur le serveur. Il faudra alors récupérer la version du serveur et fusionner avec la version local. Déploiement d'application ========================= Il est bien sur possible d'utiliser l'application avec tous les sources dans Wikitty. Mais il est aussi possible d'utiliser l'application en extrayant les sources dans des fichiers et les packagers dans un war. Dans ce cas l'application est vigée et n'est plus modifiable à l'exécution. Pour cela on utilise la servlet WikittyPublicationExternalize qui au lieu d'aller chercher les WikittyPubText et WikittyPubData dans le WikittyService va les chercher sur le système de fichiers. Dans le mode externalize les jsp et autres resources peuvent être précompilées. On peut donc avoir deux modes de mise en production suivant la taille du site ou le moment de mise en production. Par exemple pour les sites à fort volume la solution externalizée sera privilégiée ou pour les sites qui souhaites mettre à deux endroit différent l'application et les données pour des raisons de sécurites. Au contraire lors d'une phase de prototypage ou si l'on souhaite pouvoir modifier facilement l'application on utiilsera le déploiement avec l'application dans Wikitty. Statistique d'accès au pages ============================ Le ''WikittyServiceAccesStat'' permet de mettre en place les stats sur le nombre de fois qu'un wikitty a été restoré. Lors d'un restore un WikittyAccesStat(restoredWikittyId, userId, tokenId) est créé et enregistré. Le service ''WikittyServiceAccesStat ''permet par configuration de déterminer quel type de wikitty doit-être monitoré. Pour monitorer l'utilisation d'une application il faut configurer le service pour monitorer les WikittyPubText et WikittyPubData. Il est ensuite possible de sortir les stats: * nombre d'accès à une page * nombre d'accès à une page pour un utilisateur donné * nombre d'accès à une page pour un utilisateur dans une session donnée * nombre de pages accèdées par un utilisateur * nombre de pages accèdées durant une session par un utilisateur Il est ensuite possible de croiser ces stats avec les ids des pages d'une application pour connaitre le nombre de solicitation d'un user à une application. Plugin Maven ============ Il serait intéressant d'avoir les goals suivant pour maven: * ''wp-commit'' pour commiter les fichiers sur un WikittyService * ''wp-run'' lance un conteneur de servlet avec le war wikitty-publication, pousse les fichiers dans ce service pour tester en local * ''wp-verify ''essaie de compiler tout ce qui est compilable pour ressortir les erreurs * ''wp-package'' qui package l'application en mode externalize, et précompile les jsp et autres resources Application Wiki ================ Cette application commence par un WikittyPubText qui se nome Wiki. De type text/jsp. Cette page est en fait le template général de l'application (bandeau, menu, footer). Il contient des appels à l'évaluation d'autres pages avec des paramètres. Lors de l'appel de l'eval de cette page, il est possible d'indiquer aussi sur l'url une autre page à évaluer. contenu de la page:: <html> ... <div id="bandeau"><img src="<%=context.makeUrl("/raw/WikiLogo")%>"/></div> <div id="menu"><%=eval.doAction(context, "/WikiMenu")%></div> <div id="content"><%=eval.doAction(context, nextUrl!=null?nextUrl:"/WikiHello")%></div> ... </html> Ici on affiche un Logo avec l'action ''raw''. On évalue ''WikiMenu'' pour afficher le menu. Et on évalue le reste de l'url qui sert de page principale. S'il n'y a pas de suite à l'url alors par défaut on évalue ''WikiHello''. L'url d'appel pourrait-être par exemple:: /eval/Wiki/Bonzomes.list Dans ce cas le content prendra le résultat de l'évalution de ''Bonzomes.list''. Authorisation d'accès aux pages d'une application ================================================= Une application est en fait stocké dans des Wikitties, une page de l'application est un WikittyPubText, il suffit donc de mettre les bons droits sur le wikitty de cette page pour permettre ou non aux personnes d'y accéder. Les données ont déjà la possibillté d'avoir des droits et ne sont retournés à l'utilisateur que s'il en a le droit. [TODO] réflechir comment faire pour le mode externalize -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

3 2