Les
MacroWikini sont
une proposition pour améliorer la personnalisation de
WikiNi.
Les
MacroWikini ne sont pas encore réalisées.
L'objectif des
MacroWikini est de pouvoir intégrer à une page des contenus élémentaires dynamiques sans passer par les actions.
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
- fonctionnement plus rapide qu'une action (pas d'appel à un fichier supplémentaire)
- ne fait presque pas grossir l'application (ces données sont déja calculées)
Inconvénients :
- ajoute un niveau de complexité
- risque de confusion entre les actions et les MacroWikini
- risque d'être peu employées
Ces variables pourraient être appelées à partir de deux points d'interrogation : ??exemple??.
Ailleurs
Solutions techniques
... à suivre...
J'ai eu la même idée ! Très utile pour faire un menu à partir d'une page
WikiNi. Je ne vois pas pourquoi une action ne serait pas interressante. Je vois 4 avantages à utiliser une ou plusieurs actions:
- 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
- L'ajout de nouvelles macros semble complexe car cela se passe dans le fichier formatters/wakka.php puisque tu semble dire que l'utilisation d'un fichier externe est pénalisant (je ne suis pas d'accord sur ce point). Le code risque de devenir rapidement complexe.
J'ai commencé à écrire de tels actions pour les utilisers dans un menu généré par une page
WikiNi.
--
GarfieldFr
- Je suis d'accord avec toi pour les deux, voire trois premiers points. En fait je me pose des questions sur le quatrième point. Si l'on voulait reproduire le fonctionnement complet des actuels menus de WikiNi en utilisant des actions, cela voudrait dire qu'il faut utiliser des actions pour les contenus dynamiques suivants :
- le titre du wiki
- le titre de la page
- la page principale
- le login
- la date de modification
- le propriétaire
- éventuellement l'édition des permissions
- éventuellement la suppression
- les références à la page
- la version de WikiNi
- soit pas moins de 10 appels à un ou plusieurs fichier externe. Actuellement, une page de WikiNi est générée à partir de 5 ou 6 fichiers ; j'ai bien peur que le fait d'ajouter une dizaine d'appel à d'autres fichiers ne grève les performances. Cela dit, je ne suis pas un spécialiste de l'optimisation et je suis bien en peine pour évaluer cet impact. C'est la raison pour laquelle je proposais prudemment d'intégrer les MacroWikini dans les fichiers existants sous la forme d'un nouveau marqueur (??-??). GarfieldFr, sur quoi te bases-tu pour dire que le recours à ces fichiers externes n'est pas si pénalisant ? As-tu réalisé des tests ? Pour ma part, si tu me démontre la chose par A+B je serais quasiment convaincu de l'emploi des action (je demanderais encore un peu de réflexion).
--
CharlesNepote
Avec des paramètres, je pense qu'une ou deux actions sont nécéssaires pour faire ce que tu propose. Pour ce qui est de la vitesse, je pense que PHP optimise ses accès aux fichiers inclus et donc ne fera la que 2 accès au disque dur (c'est ce qui prend du temp). Je peux écrire rapidement une action et la lancer 10 ou 20 fois dans une page pour voir si cela ralentit la genération de la page.
--
GarfieldFr
J'ai ecrit une petite action qui mesure le temp écoulé et j'ai fait une page qui mesure le temp d'execution de 10 puis 20 fois la même action. Le resultat indique que le temp d'execution est proportionnel au nombre d'appel à l'action, ce qui semble logique. Tu trouvera le test à cet endroit :
http://www.multiweb.be/GarfieldFr/wikini/wakka.php?wiki=TestTempUtilisationAction
J'ai fait un test qui compare l'execution de 10 actions différentes avec 10 fois la même action (les 10 actions différentes ayant en fait le même code). Cela permet de voir l'influence du chargement d'un fichier différent pour chaque actions. Resultat : la différence de temp d'execution est inferieur à 0.005 secondes sur mon hébergeur.
Le code de l'action testé n'est pas particulièrement rapide car il fait des tests d'existance de fichier. Je pense que ce test te convaincra que l'accès à un fichier externe n'est pas vraiment pénalisant.
NB : Les actions de test n'uilisent pas la base de données.
Pour info, voici le code de l'action
{{generationtime}}:
<?php
global $debut;
global $fin;
$reset=$this->GetParameter("reset");
if ($reset) {
$debut=0;
$fin=0;
}
if ($debut==0) {
$debut = $this->GetMicroTime();
}else{
$fin = $this->GetMicroTime();
}
if (($debut<>0) && ($fin<>0)) {
$a = localeconv();
echo "Generé en ".number_format($fin-$debut,6,$a['decimal_point'],$a['thousands_sep'] )." secondes";
}
?>
Tu peux voir 2 actions permettant la configuration de
WikiNi sur mon site de test :
http://codedb.delphicenter.com/wiki/wakka.php?wiki=PagePrincipale
Il s'agit des actions
{{sysinfo}} et
{{userinfo}}
--
GarfieldFr
Ok. De toute façon, ça nous coûte toujours moins d'effort de développer des actions que de toucher au "coeur" de
WikiNi...
En revanche je ne vois pas pourquoi tu veux créer une action {{sysinfo}} et une action {{userinfo}}. Pourquoi ne pas créer une seule action {{wikini_var}} ou quelque chose de ce genre là ?
--
CharlesNepote
La création de 2 actions permet de séparer les rôles. Une action concernant les utilisateurs, une action concernant le système. Je trouve ca plus propre et plus simple à maintenir. On pourrait modéliser ça comme étant des "objets", l'objet "user" et l'objet "system" à qui on demande des informations ou des services (par exemple, mon action
{{userinfo}} comporte un service "logout" qui affiche le lien de déconnexion) . Mais biensur, on pourrait tout mettre dans la même action mais je pense que ca serait moins clair pour l'utilisateur final.
--
GarfieldFr
Moi je voyais plus une seule action du type
{{var var="user_id"}} renvoyant par exemple :
- soit "Vous êtes CharlesNepote (Déconnexion)" si je suis connecté
- soit "Vous êtes xxx.xxx.xxx" si je ne suis pas connecté.
Pour la réalisation, je voyais deux options :
Option 1
<?php
if (!$this->GetParameter("var")) { echo "Vous devez spécifier une variable à l'aide du paramètre \"var\""; }
else {
$var = $this->GetParameter("var");
eval("\$eval = \$this->$var;");
if ($result = $eval) { echo $this->Format($result); }
else { echo "<i>La variable </i>$var<i> n'existe pas.</i>"; }
}
?>
permettant ainsi d'ores et déjà d'afficher :
{{var var="page['time']"}}
{{var var="tag"}}
{{var var="VERSION"}}
{{var var="config['root_page']"}}
(OK : je sais qu'il y a un trou de sécurité dans le cas de la dernière...)
Pour ajouter des variables à la liste ci-dessus, il suffit dans wakka.php :
- d'ajouter dans la classe Wiki :
- var $variablex;
- et dans la fonction Wiki() :
- $this->variablex = $this->GetUserName?;
Avantages :
- simplification du développement de l'action
- ajout très simple des nouvelles variables
- les nouvelles variables peuvent être utilisées dans d'autres actions
Inconvénients :
- il faut faire attention au trou de sécurité potentiels
- on laisse peu de souplesse à l'action
- on alourdi le noyau de WikiNi
Option 2
<?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>";
}
}
?>
Avantage :
- tout est géré dans l'action : on peut personnaliser sans toucher au code
- on maîtrise correctement la sécurité
Inconvénients :
- il faut partir de zéro (pas très contraignant)
--
CharlesNepote
Personnellement, je verais plutot la seconde solution...d'ailleur c'est celle que j'ai utilisé pour mes actions userinfo et sysinfo. Le problème de la première solution me semble être la lourdeur de l'utilisation de l'action, le {{var var="page['time']"}} me semble complexe à utiliser par un utilisateur basic ne connaissant pas trop le code
WikiNi, et aussi potentiellement dangereux. La seconde solution me semble la plus simple pour faire évoluer les actions et le fait de partir de zéro n'est franchement pas un problème.
Pour l'action unique, je suis franchement contre :
- on melange 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.
- 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.
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 ? Puisque j'y pense en écrivant ces ligne, je vais ajouter un "service" de "connexion" à mon action {{userinfo}} comme ca on pourra mettre la saisie du login dans le menu par exemple !!!
--
GarfieldFr