Introduction
Les
MacroWikini sont
une proposition pour améliorer la personnalisation de
WikiNi.
Les
MacroWikini ne sont pas encore réalisées.
[j'ai pas mal réorganisé la page en essayant de respecter les points de vue de tous. J'ai conservé les débats originaux dans
MacroWikiniArchives --
CharlesNepote]
Besoin
L'objectif des
MacroWikini est de pouvoir
intégrer à une page des contenus dynamiques élémentaires.
Par exemple :
- le nom de l'utilisateur qui visualise la page
- les propriétés de connexion ("Vous êtes XXXX (Déconnection)" ou bien "Vous êtes machine.domaine.com")
- la version de WikiNi
- le formulaire de recherche
- le nom de la page
Le nom de
VariableWikini? serait peut-être plus juste. Ces variables sont idéalement des données systématiquement ou très souvent calculées.
Ces variables permettent par exemple d'envisager la gestion du menu non par header.php mais par une variable de configuration :
- exemple 1 : "WikiNiHeader" => "??Wiki_title?? ??Page_title??---PagePrincipale :: DerniersChangements :: ??conn_prop??"
- exemple 2 : "WikiNiHeader" => " {{include page="MenuDuWiki"}}"
(Note : dans le second exemple la configuration du menu est totalement confié à la page MenuDuWiki.)
Avantages :
- permet d'envisager plus de souplesse dans la fabrication de l'interface
Inconvénients :
- ajoute un niveau de complexité
Contraintes
Idéalement, les
MacroWikini doivent :
- être simples à employer
- avoir une syntaxe qui les rend les plus courtes possible
- ne pas ralentir l'exécution de WikiNi
Je vous propose de lister ici même tout ce que nous voulons comme différentes
MacroWikini.
Ca nous permettra de scinder le débat en plusieurs parties et de s'entendre dans un premier temps sur le contenu des macros.
- le nom du wiki non formaté, sans style et sans sémantique ; par exemple : WikiNi
- le nom de la page courante formaté, sans style et sans sémantique ; par exemple : MacroWikini
- le nom de la page racine formaté, sans style et sans sémantique ; par exemple : PagePrincipale
- le nom de l'utilisateur formaté, sans style et sans sémantique ; par exemple : CharlesNepote
- l'état de l'utilisateur, c'est-à-dire :
- soit "Vous êtes CharlesNepote (Déconnexion)" si je suis connecté
- soit "Vous êtes xxx.xxx.xxx" si je ne suis pas connecté.
- Pour les utilisateurs, il me semble plus souple d'afficher le nom de l'utilisateur et la commande de déconnexion séparement, en effet, comment fais-tu si tu veux afficher que le nom de l'utilisateur sans le lien de déconnexion ? -- GarfieldFr
- Et bien j'utilise la macro qui me permet d'obtenir le nom de l'utilisateur et non son état. Je pense qu'il y a la place pour ces deux macro différentes. -- CharlesNepote
- Pourquoi récupérer deux fois le nom de l'utilisateur? Je pense que la macro d'état ne devrait renvoyer que "Déconnexion" ou " " selon que l'utilisateur courant est ou non connecté. En l'utilisant avec la macro renvoyant le nom de l'utilisateur, on obtient la même chose en étant plus souple car on n'impose rien (en particulier le texte "Vous êtes " --GarfieldFr
- la date de modification de la page courante non formatée, sans style et sans sémantique ; par exemple : 2003-10-15 00:36:59
- posibilité de définir le format de la date --GarfieldFr
- la date de modification de la page courante formatée, sans style et sans sémantique ; par exemple : 2003-10-15 00:36:59
- posibilité de définir le format de la date --GarfieldFr
- la propriété de la page formatée en fonction du contexte, sans style et sans sémantique :
- soit "Propriétaire : vous :: Éditer permissions :: Supprimer"
- soit "Propriétaire : DavidDelon"
- soit "Pas de propriétaire (Appropriation)"
- les références externes à la page
- la devise de l'utilisateur : ça sert à rien mais ça peut "faire beau" de la mettre dans l'en-tête ou le pied de page par exemple.
- la table des matières (ou sommaire) d'une page ou d'un groupe de pages. Ceci pourra être implémenté lorsque nous aurons les ancres automatiques pour les titres.
- Pour moi, c'est plutôt une action indépendante qu'une macro. L'idée de la macro "est de pouvoir intégrer à une page des contenus dynamiques élémentaires. Les macros devraient permettre une personnalisation de WikiNi, comme par exemple la possibilité d'inclure tous les éléments du menu du haut dans une page et de simplement indiquer cette page comme étant la page de menu. Une table des matières n'est pas vraiment un contenu élémentaire. Par contre l'idée est à retenir pour une action ! --GarfieldFr
- Oui tu as raison -- PatrickPaul
- Ce qui précèdent sont des actions "donner telle information". Il faut généraliser. L'utilisateur voit des actions sur des variables pas des variables. Wikini est un objet que je manie , sur lequel j'agis pour obtenir quelque chose.
J'ai donc "besoin" d'une "action".... (Mais je comprends très bien que le développeur y voit des variables ;-o)
- pour changer de style (changestyle superbe) ... à chaque page. Est-il possible de changer la couleur du fond sans avoir à créer un autre fichier css ? par exemple...
- pour poser une question
- et pour inscrire la réponse ici ou là .... La page Paramètresutilisateur ne la fait-elle pas déjà ?...tiens! je vais aller soulever son capot
- ou pour changer de page ou modifier son contenu
- pour écouter une musique à l'ouverture/la lecture/la fermeture de la page
- pour ouvrir une fenêtre d'aide à l'ouverture d'une page....et tenant compte ou non d'un paramètre inscrit dans la page...
Ces actions ne sont pas liées à un début, une fin de page mais à tout ou partie de la page...
--
FidelioEspoir
Ailleurs
Solutions techniques
Solution 1 : des actions spécialisées
Des actions spécialisées permettent d'afficher des données spécialisées sur le système, les utilisateurs, etc.
On verra à ce titre les deux actions développées par
GarfiledFr? :
Avantages :
- C'est très simple à coder
- C'est facilement extensible à l'infini
- L'utilisation d'action permet de regrouper par catégorie les demandes. Par exemple une action donnant des infos sur la page actuelle, une action donnant des infos sur l'utilisateur...etc
Inconvénients :
- d'après CharlesNepote : chaque nouvelle action ajoute un degré de complexité pour l'utilisateur final
- la syntaxe est longue : ne permet pas d'envisager des raccourcis syntaxiques
- des paramètres redondants doivent être codés plusieurs fois (style, formatage, etc.)
Solution 2 : une seule action
Cette solution voit la création d'une seule action, par exemple, {{var}} pour traiter tous les besoins en terme de macro.
Par exemple :
<?php
if (!$this->GetParameter("var")) { echo "Vous devez spécifier une variable à l'aide du paramètre \"var\""; }
else {
switch($var)
{
case "user":
echo $this->Format($this->GetUserName());
break;
case "page":
echo $this->Format($this->GetPageTag());
break;
default:
echo "<i>La variable </i>$var<i> n'existe pas.</i>";
}
}
?>
Avantages :
- tout est géré dans l'action : on peut personnaliser sans toucher au code
- on maîtrise correctement la sécurité
- l'utilisation est simplifiée : une seule action regroupe toutes les variables
- l'utilisation d'une seule action rend possible la création d'un marqueur particulier dédié à cette action : au lieu d'écrire {{var var="user_name"}} on pourrait donc écrire : ??user_name?? ce qui est sensiblement plus court, moins complexe et plus facile à mémoriser
- l'utilisation d'une seule action facilite l'intégration de paramètres génériques comme "style" (affectant une classe de style au contenu) ou "format" (indiquant la nature du contenu, formaté ou brut), etc.
Inconvénients :
- avec une seule action, la taille du code risque d'enfler au fur et a mesure que l'on ajoutera des services à cette action ce qui le rendra moins souple et facile à corriger et maintenir.
- d'après GarfieldFr : "on mélange les ressources, avec plusieurs actions, les ressources (info, méthode) d'un utilisateur sont sur une action, les ressources concernant le système sur une autre...etc." ; je ne suis pas d'accord avec cette remarque : une variable reste une variable, je ne vois pas pourquoi il faudrait à tout prix les séparer -- CharlesNepote
Je pense qu'il faut relativiser l'inconvénient de la taille du code : je ne vois pas
WikiNi avoir plus d'une trentaine de variables, même à long terme... --
CharlesNepote
Tout a fait, il est peu probable que
WikiNi ait plus d'une trentaine de variables. Mais mon argument principale sur la séparation en plusieurs actions est la "catégorisation" des variables (c'est peut être plus clair comme cela). Cela permet de représenter une action comme un objet pour l'utilisateur, cet objet propose des attributs et éventuellement des services (ie méthodes). De plus, le nom des variables est plus simple : si l'on dispose de 2 actions {{sysinfo}} et {{userinfo}}, on obtiendra le nom de l'utilisateur courant en utilisant {{userinfo info="name"}} et le nom du site wiki en utilisant {{sysinfo info="name"}} (par exemple). --
GarfieldFr
Discussions
Ces variables pourraient être appelées à partir de deux points d'interrogation : ??exemple??. --
CharlesNepote
Par contre, l'utilisation de la syntaxe ??user_name?? est tout à fait pertinente, mais la question est de savoir à quoi vont servir ces macros. Il est peu probable que l'utilisateur lambda utilise les macros car elles sont destinées à la mise en forme du wiki :
Les MacroWikini sont une proposition pour améliorer la personnalisation de WikiNi.. A priori, seul l'administrateur du wiki devrait utiliser ces macros et la facilité d'utilisation devient un argument peu convainquant. --
GarfieldFr
- De quel administrateur parles-tu ? L'administrateur fonctionnel (celui qui gère la vie "éditoriale" du wiki) n'est pas forcément le même que l'administrateur technique (celui qui gère le wiki au niveau technique (installation, sauvegarde, maintenance technique)). Les administrateurs fonctionnels peuvent être des non-techniciens : pour moi, la facilité d'utilisation devient alors un argument important. -- CharlesNepote
Une idée sur la syntaxe de ces/cette action, plutôt qu'écrire {{var var="user_name"}} il serait mieux d'écrire : {{var/user_name}}.
Pourquoi ? Simplement pour pouvoir passer des paramètres à un service de l'action. Par exemple, imaginons un service "un_service" rendu par l'action "var", ce service peut prendre des paramètres en entrée. La syntaxe deviendrait alors : {{var/un_service="liste des paramètres"}}. Avec une telle syntaxe on se rapproche beaucoup du concept de macros, c'est à dire une fonction executée par le système.
Pour voir un exemple de service:
http://codedb.delphicenter.com/wiki/, la zone d'identification est un "service" fourni par l'action {{userinfo}}.
--
GarfieldFr
- 1. A propos de la syntaxe {{var/user_name}}, je souhaitais qu'elle disparaisse progressivement de WikiNi, étant à la fois peu intuitive et peu habituelle ; je lui préfère la syntaxe {{var content="user_name"}} qui a le mérite d'être proche de celle du HTML : <BALISE ATTRIBUT="valeur">. Nous avons conservé hélas la vieille syntaxe pour des raisons de compatibilité.
- 2. La syntaxe {{var/un_service="liste des paramètres"}} me paraît très confuse et très éloignée de ce qui se fait actuellement sur WikiNi.
- . -- CharlesNepote
- Ok pour le point 1
- Pour le point 2, une autre syntaxe possible : {{var name="nom_du_service" params="param1;param2;param3"}}
- .--GarfieldFr
Peut-être peut-on envisager de créer la notion d'alias : ??user_name?? étant un alias renvoyant à l'action {{var content="user_name" style="name"}}. --
CharlesNepote
Je ne pense pas que faire un alias soit nécessaire, en effet, ces macros ne seront que très peu utilisées et par des personnes qui savent ce qu'elle font (en principe), en général se seront les responsables du wiki. De plus, une syntaxe courte du style ??xxxxx?? rendrait l'utilisation confuse, dans
WikiNi, les symboles de ce style sont plutôt réservés au formatage du texte, ici il ne s'agit pas d'une mise en forme. --
GarfieldFr
AMHA: Un wiki conformément à sa philosophie, ne doit pas séparer les "utilisateurs qui savent" et "ceusse qui savent pas". Il ne doit pas privilégier un niveau d'administration (sauf celui d'accès à la base de donnée, privilège/responsabilité social reconnu par le fait de la création du wiki. Tous sont maintenant capables d'écrire dans une page. Ils rêvent déjà d'y dessiner, d'y réfléchir... Ils rêveront d'y agir.
Pour maintenir la facilité d'
écrire, il faut bannir le plus possible toute syntaxe nouvelle, toute règle syntaxique nouvelle. Donc gardons
{{nomaction nomparamètre=valeurparamètre...}}.
Pour maintenir la facilité de
comprendre, il faut maintenir ce dossier "actions" et y regrouper toutes les actions. L'utilisateur n'a plus à chercher dans la jungle des fichiers. Il sait qu':
- Une action sur une partie de la page est dans "actions".
- Une action sur toute la page est dans "handlers/page/". Tiens se dit-il, pourquoi ce dossier page qui s'ennuie tout seul ? extension future ?
- Une action sur l'apparence du texte est dans "formatters". Tiens se dit-il, pourquoi les fichiers.css n'y sont-ils pas ?
- Une action "pouvoir-voir-une-image" qu'il identifie à "image" est dans le dossier "image". Tiens se dit-il, pourquoi n'existe-t-il pas ?
- Une action "agir" permet de commander une action quand il le veut (ah le merveilleux "do field "cequejeveux" d'hypercard" qui me permettait de libérer l'utilisateur du développeur-qui-prévoit-tout-sauf-ce-que-je-veux-faire ;-o)) Tiens se dit-il, pourquoi n'existe-t-elle pas...
- Une action "renseignersurl'action" est toujours disponible en écrivant {{nomaction ?}}. Zut se dit-il ça manque, il va falloir que je cours dans le web pour savoir. L'utilisateur n'aime pas demander depuis l'école où le non-savoir est condamnable...
--AMHA d'utilisateur insatiable,
FidelioEspoir
Pour faire avancer le sujet, je propose de compléter tout d'abord la section ""Proposition de
MacroWikiNi". --
CharlesNepote
CharlesNepoteASuivreEnPriorite PatrickPaulASuivre PageSuivieParGarfieldFr GiJoASuivre