Statut de cette page :
Ici s'est déroulé une bonne partie du projet de mise en oeuvre des namespaces : discussions, cahier des charges, questions, précisions, formalisation, cahier de recettes, etc.
Cette page contient donc de la documentation du projet. A terme, nous n'aurons besoin que d'une documentation du fonctionnement et de la mise en oeuvre. Pour remplir ces deux besoins, cette page doit donc, soit encore évoluer, soit donner naissance à d'autres pages.
Autres ressources :
Les Namespaces en deux mots
Les namespaces rendent possible la création de sous-pages, voir d'espaces de pages complets ayant leur propre autonomie -- on parle aussi parfois de
WikiFractalite??. De nombreux wiki permettent l'usage de namespaces (phpWiki, xwiki, pmwiki,
WackoWiki, etc.), avec plus ou moins de fonctions associées. On verra notamment deux moteurs de wiki qui font un usage riche des namespaces :
Concrètement, les namespaces rendent possible d'avoir des pages intitulées de la manière suivante :
- Discussions.Namespace
- WikiNi05?. Documentation.Actions.RecentChanges?
- WikiNi05?. Documentation.Actions.BackLinks
Ce qui différencie les namespaces d'une pure ferme de wiki :
ou - un compte créé dans un wiki d'une ferme ne fonctionne pas nécessairement sur les autres wikis de la ferme ; au minimum, au sein d'une même ferme, ce compte ne peut avoir par défaut les mêmes droits d'un wiki à l'autre
Intérêts
- une meilleure lisibilité du nom des pages
- possibilité de créer des sous-wikis
- facilite fortement la structuration des contenus ; exemple : DocUtilisateur?.WikiNi04?.CommentModifierUnePage (bien utile pour l'OrganisationDeLaDocumentationDeWikiNi)
- la possibilité de fonctionnalités qui ne fonctionnent que pour le namespace en cours (DerniersChangements, etc.)
- ils sont transparents pour ceux qui ne veulent pas les utiliser
- la possibilité d'avoir des noms plus court dans le menu de gauche
Usages
- structuration d'un wiki en plusieurs sous-parties autonomes
- possibilité de créer des blikis (blogs + wiki) ? (cf. MeatBall:WikiLog (interwiki) (interwiki) et le bliki de ChristopheDucamp)
- mini ferme de wikis (tous basés sur la même racine) ; une seule installation du moteur pour gérer plusieurs espaces
Scénario d'usage des namespaces
Scénario d'un wiki massivement multilingue :
- namespaces : je crée un namespace par langue
- le menu : est différent pour chaque namespace (traduit dans la langue concernée) ; il permet à chaque utilisateur de se sentir chez soi dans son namespace linguistique
Scénario espace privé:
- namespaces : tout le wiki est ouvert sauf un namespace clairement identifié où toutes les pages sont réservées à un groupe
- le menu : pour aider les utilisateurs de la partie réservées, il y a un menu spécifique pour cette partie, qui n'est cependant pas affiché pour les autres
Scénario wiki de projets ou d'école :
- namespaces : chaque projet/classe, potentiellement des dizaines ?, a son namespace contenant chacun des dizaines de pages
- le menu : assure une navigation dans le site et surtout dans chaque namespace en cours
Scénario site de wikini :
- namespaces : on évite de multiplier les namespaces mais un namespace par version de wikini nous est utile pour la documentation ; à chaque nouvelle version on recopie le namespace de la doc de la version précédente pour élaborer la doc au fur et à mesure du développement de la future version
- le menu : le fait d'avoir peu de namespaces permet d'avoir un menu unique pour tout le wiki, contenant la nav globale et des liens vers certaines pages particulière avec un sous menu spécial pour la doc de la dernière version
Cahier des charges complet
Nomenclature des namespaces
- Il est possible d'avoir plusieurs niveaux de namespaces ; c'est-à-dire qu'on peut créer un namespace dans un namespace.
- Le . (point) est retenu comme séparateur de namespaces (un peu comme les packages en Java), mais WikiNi pourra aussi être paramétré pour utiliser le / (slash), ou tout autre séparateur.
- Les noms des pages racines conservent les règles de nommage de WikiNi et ne sont donc pas obligatoirement des MotsWiki ; on peut ainsi forcer un lien en écrivant unepageracine.unesouspage.
- Une règle de distinction précise permet de distinguer un nom de page qui serait semblable à celui d'un handler.
- La solution consistant à faire commencer tous les noms de handlers par un "_" est écartée car cette voie représente une rupture trop importante par rapport aux conventions antérieures de WikiNi.
- Comme dans PmWiki?, le dernier terme après le dernier "/" est le nom d'un handler (handler "show" s'il n'y a rien après le "/") ; cet aspect est formalisé plus loin dans cette page
Opérations de création et droits d'accès
- A sa création, un namespace hérite des propriétés et fonctionnalités de son père
- A la création d'une nouvelle page dans un namespace donné, celle-ci hérite des droits d'accès de la page racine du namespace.
- En l'absence de page racine, la nouvelle page créée hérite des droits par défaut du Wiki
- La modification des droits d'accès d'une page racine ne modifie pas directement les droits d'accès des pages filles, mais n'affecte que les pages créées ultérieurement.
- Autrement dit, si les les droits d'une page racine sont modifiés, ceux des pages filles doivent être modifiés expressément (et, en l'absence d'un outil d'automatisation, unitairement).
- Une page peut être créée dans un namespace sans que la page racine du namespace n'existe. Exemple : une page MonProjet?.Phase1? peut exister si MonProjet? n'existe pas (comme dans PmWiki?)
- Un utilisateur enregistré le sera pour tous les namespaces
- Un groupe d'utilisateur donné peut être listé dans n'importe quelle Liste de Contrôle d'Accès (ALC), indépendamment de la page ou du namespace. Autrement dit, un groupe d'utilisateurs "fonctionne" sur tous les namespaces.
Fonctionnement des liens
- Dans un namespace donné, un MotWiki simple renvoie à une page du namespace en cours (idem PmWiki?)
- Le formateur de texte ne reconnaîtra pas automatiquement les liens précisant un namespace. Ceux-ci devront obligatoirement être forcés avec la syntaxe ....
- Autrement dit, le séparateur de namespaces, quel qu'il soit ("/" ou bien "." ou autre), sera un séparateur linguistique. Dans XXX.SousPage?? : SousPage?? sera donc un mot wiki à part entière.
- Par exemple :
- Pageracine.SousPage? ne produira que le lien correspondant au MotWiki SousPage?
- PageRacine?.SousPage? produira les deux liens qui correspondent auw MotsWiki PageRacine? et SousPage?
- Une règle précise permet de distinguer les cas où un lien fait référence à des sous pages, de ceux où il référence des pages à partir de la racine du wiki.
- Les liens (forcés) précédés du caractère / seront de type absolus : ils devront préciser tous les namespaces qui permettent de localiser la page cible. Par exemple :
- Dans une page appelée PageRacine?.PageUn?, l'expression /NameSpace.PageDeux fera référence à la page NameSpace?.PageDeux? (à compter de la racine) ;
- Dans la même page, l'expression NameSpace.PageDeux référencera la page PageRacine?.NameSpace?.PageDeux? (à compter de la racine).
- Le caractère / qui précède les liens absolus ne permettra que de désambiguïser le lien : il ne fera pas partie du lien généré et ne s'affichera pas.
- Le handler pourra désormais être précisé dans un lien forcé.
- Dans le cas où le séparateur de Namespace est paramétré sur / au lieu de ., une règle précise permet de distinguer le handler d'une sous page.
- Pour les liens qui comporteront un ou plusieurs caractères /, la partie située après le dernier / désignera obligatoirement un handler, et pourra éventuellement être vide.
- Exemples :
- Dans le cas particulier où le nom d'un handler est utilisé comme un nom de page, les liens devront donc être fermés avec un caractère / (slash) ; par exemple :
- XyXy?/ZaZa?/edit => handler edit
- XyXy?/ZaZa?/edit/ => handler show
- edit => handler show
- edit/edit/ => handler show
- edit/edit => handler edit
- Le caractère / qui terminera les liens utilisant le handler par défaut permettra de désambiguïser le handler : il ne s'affichera pas, mais il fera partie du lien généré.
Pages des utilisateurs
- Un utilisateur est-il défini dans tous les namespaces (c'est-à-dire qu'il n'a rien à faire pour profiter partout de toutes les fonctionnalités permises par son compte) ? -> Oui.
- Un utilisateur a-t-il une seule page de présentation ou bien peut-il avoir des pages de présentation différentes selon les namespaces ?
- pour simplifier l'usage, la page de présentation initiale d'un utilisateur devrait constituer une référence unique accessible d'un seul clic depuis n'importe où
- mais il devrait être possible de définir une page spécifique pour un namespace donné
- comment l'utilisateur doit-il procéder ? (fonctionne actuellement en tapant manuellement l'adresse que cette page devrait avoir)
- Cette question est à mettre dans la todo-list. Elle est mise de côté pour l'instant. -- BenjE?
- il faut dans ce cas que cela fonctionne aussi pour les sous-namespaces -- DidierLoiseau
- Peux-tu préciser ta remarque ? --BenjE?
- actuellement, si je crée TelNameSpace?.DidierLoiseau, ce n'est pas cette page qui sera utilisée si je signe dans TelNameSpace?.SousNameSpace?.TellePage?: c'est Contributeur.DidierLoiseau qui le sera. Pour moi ceci n'est pas cohérent (mais je reste convaincu que ce n'est pas une bonne chose de créer une page utilisateur dans un namespace, ça va prêter à confusion sans apporter grand chose…) -- DidierLoiseau
- Oui, je vois ce que tu veux dire. Concernant l'impossibilité de raffiner les pages des utilisateurs, ça pourrait être paramétrable à moindre frais. En gros (j'écris de mémoire sans vérifier) ça se passe dans ComposeLinkToPage??(). Quand on détecte une page utilisateur, on peut faire un LoadExactPage??() au lieu d'un LoadPage?(). Veux-tu ajouter un paramètre pour cela ? -- BenjE?
- À vrai dire c'est peut-être aux utilisateurs de ne pas créer de pages utilisateurs dans les autres namespaces. Ce n'est donc pas indispensable de l'empêcher expressément. Tant que le comportement par défaut encourage l'utilisateur à créer sa page dans le namespace Contributeurs. -- DidierLoiseau
- il est impératif que la consultation d'une page d'un utilisateur conserve un accès rapide et intuitif aux pages et outils du namespace dans lequel l'utilisateur est au moment où il s'en va consulter une page utilisateur.
- Aïe, ça ne marche pas comme ça aujourd'hui. Quand on consulte une page utilisateur, on bascule dans le namespace "Contributeur", qui devient donc le contexte d'interprétation des liens. J'ai préféré ça pour que les contributeurs "voient" que leur page personnelle est unique dans tout le Wiki. (Et ça me semble le plus logique.) Veux-tu vraiment que je revienne sur ce choix ? Comme le suggère Didier, les utilisateurs peuvent utiliser le bouton "précédent" du navigateur pour revenir dans le namespace où ils étaient. -- BenjE?
- Les pages des utilisateurs seront définies dans un namespace spécifique, dont les pages sont exposées dans tous les namespaces
- Ce namespace spécifique est choisi à l'installation.
- Je ne pense pas cela nécessaire, même si c'est déjà implémenté. Le seul intérêt que j'y vois c'est pour WakkaLocalization, mais doit-on se préoccuper de cela pour l'implémentation des namespaces ? -- DidierLoiseau
- Bah, la localisation, mieux vaut s'y prendre à l'avance qu'en retard. -- BenjE?
- Oui, certes. Mais je ne pense pas qu'il soit vraiment utile de pouvoir configurer cela à l'installation. C'est vrai que par la suite il est difficile de changer s'il y a déjà des pages utilisateur créées mais bon… -- DidierLoiseau
- Quand on navigue dans un namespace donné, si la page d'un utilisateur n'existe pas dans ce namespace, le lien pointera automatiquement vers la page correspondante dans le namespace des utilisateurs.
Fonctionnement des actions et des handlers
- permet d'associer des fonctionnalités particulières à un namespace :
- actions spécifiques à un namespace : RecentChanges?, RecentChangesRSS?, RecentComments?, ResentCommentsRSS?, Backlinks, ActionListPages, PageIndex?, TextSearch?, etc.
- par défaut, ces actions s'appliquent au namespace en cours et ses sous-namespaces
- un paramètre permettra de préciser la portée de l'action : soit globale, soit sur tel ou tel autre namespace ; idéalement on pourra préciser dans ce paramètre une liste de plusieurs namespaces sur lesquels portera l'action (séparés par exemple par des virgules)
- ActionListPages
- Lorsqu'on démarre de la page d'un utilisateur, doit-on toujours interpréter cette page comme étant dans le namespace courant ? -- BenjE?
- Il me semble que oui. Les pages des utilisateurs étant dans le namespace racine, étant qu'une action s'applique pour le namespace en cours et ses sous-namespaces, alors l'action ActionListPages listera toutes les pages de tous les namespaces relative à tel utilisateur. -- CharlesNepote
- RecentChanges?
- Un paramètre permettra d'étendre la recherche de pages modifiées aux sous-namespaces.
- editactionsacls.class.php
- editgroups.class.php : pouvoir habiliter un groupe sur une page de namespace. (Cette habilitation sera héritée par les pages qui seront ensuite créées dans ce namespace)
- En fait, si une page de namespace est une page comme les autres, il n'y aura rien à changer dans editgroups.class.php.
- edithandlersacls.class.php
- erasespamedcomments.class.php : cette action porte par défaut que sur le namespace courant
- CSS spécifique (dans un deuxième temps, ces feuilles CSS pourraient être des pages spécifiques du wiki)
- paramètres de config spécifiques à un namespace ("wakka_name", "root_page", "navigation_links", "referrers_purge_time", "pages_purge_time", "default_write_acl", "default_read_acl", "default_comment_acl", "meta_keywords", "meta_description", "preview_before_save", "allow_raw_html")
- suppression d'un namespace (c'est-à-dire suppression de toutes les pages appartenant à un namespace) ; on peut supprimer la racine d'un namespace (qui est une page comme une autre) sans pour autant supprimer les pages du namespace. Cela prendra la forme d'un nouvelle action (DeleteNamespace?? ?), réservée par défaut aux admins, comportant des mécanismes permettant de bien lister ce qui est supprimé et de confirmer la suppression.
- comportement spécifique des handlers à voir :
- edit.php => RAS
- show.php => RAS
- xml.php => RAS
- backlinks => RAS
- svg => RAS
- prévoir un handler "context" (comme dans prowiki) permettant de paramétrer chaque namespace (CSS, paramètres de config, etc.)
Interface et ergonomie de navigation
- Tout comme dans le namespace racine (option de configuration "navigation_links"), il est possible de spécifier un menu de navigation spécifique à chaque namespace
- Comme pour toutes ses autres propriétés, un namespace hérite par défaut du menu de navigation de son parent
- Par défaut, le menu de navigation contient :
- un lien vers les derniers changements du namespace en cours
- un lien vers les derniers commentaires du namespace en cours
- un lien vers les paramètres utilisateurs : une fois dans cette page, l'utilisateur doit pouvoir revenir simplement de la page ou d'une fonctionnalité du namespace d'où il venait (cette dernière fonction pourra être réalisée par les boutons "précédent" et "suivant" du navigateur)
- un lien vers une page décrivant l'utilisateur
- Header : modifier l'affichage du header pour faire apparaître le nom de la page "Namespace . NomDePage??" et permettre de cliquer sur "Namespace" pour revenir à la racine du namespace.
- Footer : ajouter une liste de sélection pour exécuter la recherche de texte sur le namespace en cours ou sur tout le wiki ; ou bien faire une recherche par défaut sur le namespace en cours et proposer dans la page de résultats d'étendre la recherche à d'autre namespace (comme dans wikipédia ou craowiki)
Implémentation
L'implémentation peut être progressive.
Version 1
La version 1 se contente de mettre en place les namespaces et d'en gérer les mécanismes et services de base. Dans cette version la portée d'une action :
- est par défaut le namespace en cours
- peut-être un autre namespace, spécifié par un paramètre
exemple : {{recentchanges namespace="/Documentation"}}
- D'abord permettre le nommage de page type "Namespace/NomDePage??" (quelques heures). Fichiers et méthodes impactés :
- /wakka.php :
- le découpage page/méthode (" split into page/method")
- La méthode SavePage?() (droits par défaut),
- La méthode MiniHref?()
- La méthode Link()
- /formatters/wakka.php
- /actions/header.php
- Puis coder les fonctionnalités de base relatives aux namespaces
- en commençant par les RecentChanges?, RecentChangesRSS?
- options de configuration (dans wakka.config.php)
- droits d'accès
- handlers : acls.php, backlinks.php, edit.php, resetstyle.php, show.php, svg.php, xml.php
- Coder ensuite les fonctionnalités de seconde importance (peut-être dans la V2)
- par ordre d'importance : Backlinks, TextSearch??, ActionListPages, PageIndex??, etc.
- La méthode IsOrphanedPage?() du noyau doit être modifiée pour ne prendre en compte que les pages du namespace de la page
- La méthode FullTextSearch?()
- L'interface de recherche dans /actions/footer.php
Version 2
La version 2 étend les fonctionnalités de la version 1.
- possibilité de spécifier plusieurs namespace en paramètre d'une action donnée
- ActionListPages : ajouter un paramètre pour lister les sous-pages d'une page, sous forme d'arborescence
- handler "context" permettant de paramétrer chaque namespace (CSS, param de config, etc.) (comme dans ProWiki?)
- CSS spécifiques
- Les pages CSS pourront être des pages Wiki spéciales, ce qui en simplifiera la modification.
Cas de test pour les namespaces
Attention : ces cas ne sont pas finalisés et peuvent évoluer
Pour avoir une vue synthétique des syntaxes possibles et de leur comportement, je les ai listées ici. Cette liste tient également lieux de proposition puisque j'y précise notamment certains aspects non décrits ci-dessus.
Rappel des principes de base :
- on recherche à ne pas dérouter l'utilisateur habituel de WikiNi
- un MotWiki normal renvoie à une page du namespace en cours
- un mot sans mention de protocole entre double crochet renvoie à une page du wiki
- tout comme Accueil renvoyait à la page "Accueil" dans WikiNi 0.5 et antérieurs, en suivant le principe selon lequel un namespace possède sa vie propre, cette dernière chaine renvoie donc à la page "Accueil" du namespace en cours
Les choses qui me posent question :
- ces règles introduisent des écarts entre la syntaxe wiki et l'URL (ce qui est dommage) :
- peut-être, du coup, aurait-on intérêt à utiliser le point comme séparateur du handler : /PagePrincipale/edit serait une page et /PagePrincipale.edit ou
/
PagePrincipale/edit.edit une édition
- ou bien faut-il revoir le caractère séparateur et choisir le point (par exemple, que je trouve néanmoins moins intuitif) : /PagePrincipale.NameSpace1? ou
/
PagePrincipale.
NameSpace1?/edit
- ça ne résout pas le problème de la syntaxe permettant de spécifier qu'une page est à la racine
Cas de test
- DiscussionsNamespacesCasDeTestAvecLePoint?
- DiscussionsNamespacesCasDeTestAvecLeSlash?
Le séparateur retenu est le point.
Le "/" est, peut-être, plus intuitif pour les utilisateurs (notamment lorsqu'on utilise la réécriture d'URL). Le / donne une idée plus claire de la hiérarchie. Il est déjà présent dans des milliards d'URLs. Les unxiens et maceux ne sont pas déroutés. Mais le "/" possède des inconvénients notables : rendre les titres moins visibles et complexifier la compatibilité ascendante de
WikiNi (car il sert à départager les handler).
Le point offre une meilleur lisibilité.
Cahier de recettes
- la recherche est restreinte au namespace en cours, mais cliquer à nouveau sur [Chercher] permet de l'étendre à tout le wiki (ce qui n'est pas clairement indiqué à l'utilisateur…)
Choses faisant discussion
Ce que nous proposons dans cette page reprend grosso modo et précise ce qui a été décrit dans
GestionDeGroupeDePages et
ErgonomieGroupeDePages.
Quelques points portent à discussion.
- La syntaxe des liens
DidierLoiseau préconise : "ils faut donc permettre le point dans les mots wiki".
CharlesNepote pense que les mots wikis ne changent pas et qu'il faut employer des doubles crochets pour faire des liens hors namespace. De cette manière, on ne change pas le comportement du formatter et une faute de frappe ne risque pas de créer un mot wiki...
Xf75013? préfèrerai voir le caractère underscore _ qui permettent d'identifier clairement les mots pour un résultat sémantique plus "propre", plutôt que le point qui a une toute autre signification. De toute façon c'est une première étape car le futur wikini internationalisé qui devra probablement être encore plus souple !