Wikini

DiscussionsNamespaces

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-44-204-164-147.compute-1.amazonaws.com

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 :



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




Usages




Scénario d'usage des namespaces

Scénario d'un wiki massivement multilingue :

Scénario espace privé:

Scénario wiki de projets ou d'école :

Scénario site de wikini :


Cahier des charges complet

Nomenclature des namespaces



Opérations de création et droits d'accès



Fonctionnement des liens



Pages des utilisateurs




Fonctionnement des actions et des handlers



Interface et ergonomie de navigation




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 :
exemple : {{recentchanges namespace="/Documentation"}}


  1. 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

  1. 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

  1. 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.


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 :


Les choses qui me posent question :

/PagePrincipale/edit.edit une édition

/PagePrincipale.NameSpace1?/edit


Cas de test


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



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.

  1. 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 !


Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]