Wikini

LaurentLunatiSkin

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-54-166-133-84.compute-1.amazonaws.com

templates et habillage

(Recommandation de CharlesNepote : attention de bien séparer la page entre les aspects fonctionnels et techniques.)
(J'ai complètement reformulé nos discussions pour plus de lisibilité. J'espère avoir respecté tous les points de vu. Naturellement on peut toujours rediscuter. -- CharlesNepote)

Expressions des besoins fonctionnels

Pour l'accessibilité je pense qu'il y a besoin de pousser un peu le réflexion sur les placements et le nommage des divers éléments. Par exemple le footer contient essentiellement des éléments en rapport avec la page vue, la logique m'a incité à douter de la zone ciblé par la recherche (la page ou tout le site?), il a fallu que je teste pour savoir. -- LaurentLunati

Rappel de la structure actuelle

Structurellement WikiNi les pages de WikiNi sont actuellement ainsi formées :

Proposition de nouvelle structure et de besoins fonctionnels

Après quelques discussions, nous proposons une nouvelle structuration des contenus :
(notez : 1. la disparition du lien obligatoire vers la page principale dans le menu de navigation, 2. la sortie de l'identification du menu de navigation, 3. la disparition du formulaire de recherche du précédent menu relatif à la page, 4. de la sission en deux sous-menus du précédent menu relatif à la page. 5. L'ajout du menu d'accessibilité)
Question en suspend : la recherche doit-elle être un bloc à part ?

En termes fonctionnels, nos besoins sont les suivants :

(1) Il existe des cas, certes marginaux, où un administrateur peut désirer ne pas faire apparaître ces contenus : le nom peut être dans le corps de chaque page et il est donné dans la balise <title> ; idem pour le nom de la page ; les actions sur la page peuvent être entrées à la main dans l'URL ; le menu n'est pas nécessaire ; (cf. l'exemple de http://www.meridon.com/ où on voit que le nom de la page et les actions sur la page n'apparaissent pas). Il n'y a donc qu'un et un seul contenu indispensable : le corps de la page, tous les autres étant optionnels.
-- LaurentLunati et CharlesNepote


Pistes de solutions



Je n'ai pas changé d'opinion sur les templates, au bout d'un moment, par "amélioration" successive on se retrouve avec un veritable language (cf spip ou templeet), je rappelle que php, lui même, était au départ une extension html que l'on peut considérer comme un template. Donc mon avis sur la question : des templates pour développer Wikini : non. -- DavidDelon
PS : voici un exemple de ce que l'on peut trouve dans http://www.templeet.org [fr] :
Ceci est un template utilisé pour ~get_filename()

~set('count',1)
~while(~get('count')<=3,
  'je compte ~get('count')
~set('count',~get('count')+1)')


Je suis assez d'accord avec ce point de vue, le template ne devrait pas dériver vers ce type de chose. Reste qu'il est nécessaire de pouvoir choisir l'ordre d'apparition des élément dans la page, et de jouer sur les imbrications de div. Cela pour plusieurs raisons, tout d'abord, d'un site à l'autre, les éléments importants ne seront pas forcement les même, les objectifs de ces sites non plus. Si par exemple je souhaite consulter mon site en grande partie avec un pda , la logique d'apparition des divers éléments sera guidé par cette contrainte, et dans ce cas la css est inefficace. De plus pour tirer pleinement partie des feuilles de style, il faut aussi pouvoir modifier un peu les jeux d'imbrications, css zengarden est un bel exemple mais il faut aussi penser que le html à été spécialement conçu à cet effet, chaque paragraphe ayant été codé avec un id propre, donc impossible à réaliser avec un wiki. J'avais fait un petit exemple basé sur les listes pour montrer qu'il est possible de faire beaucoup à partir des css mais que cela demande parfois quelques petits "aménagements". www.orogram.com/Documents/listes.html --LL

Je suis sensible à ces arguments. Pour autant la solution du template dans le source de Wikini me semble lourde. La solution de MacroWikini proposée par CharlesNepote ne conviendrait-elle pas ? -- DavidDelon
<div id="pageHeader">

les inclusions systématique de span dans les balises permettent d'avoir à minima deux niveaux par éléments, ce qui facilite grandement l'habillage (notamment les blocs encadrés) en appliquant le principe à l'ensemble des balises on arrive à quelque chose d'assez agréable à skinner je pense --LL


Solution technique pour ordonner les contenus

L'ensemble de fichiers nécessaire à une skin doit donc comprendre :

Le (les) fichier décrivant l'ordre d'apparition, sert aussi à placer les classes et id
-- LaurentLunati

Il existe d'autres solutions, comme la possibilité d'éditer directement dans une page wiki l'ordre d'apparition des éléments et la feuille de style (une page pour chacun) : cette solution pose les mêmes problèmes que j'ai mentionnés ci-dessous. Elle rencontre également un autre problème : si l'ordre d'apparition des éléments est effectué dans une page wiki, alors il faut prévoir un mécanisme qui empêche l'administrateur de supprimer l'élément "corps" qui lui est justement nécessaire pour configurer la présence et l'ordre des éléments. -- CharlesNepote


Question de la modularisation du menu sous la forme d'une page Wiki

C'est quelque chose que l'on voit fréquement sur des wikinis personnalisés (nous l'utilisons nous-même en intranet). Je suis partant pour une telle modularisation mais elle pose des problèmes fonctionnels sur lesquels il faut réfléchir.

Je traiterai seulement du cas 1 qui est le plus intéressant mais aussi le plus problématique.

1. Modularisation à travers une page du wiki.
Cette page est-elle créée à l'installation ? A priori oui, je ne vois pas bien d'autres solutions sans compliquer l'installation.
Quels droits d'accès possède cette page à l'installation ?
-- CharlesNepote


Exemple de solution avec PhpWiki

Par exemple, ce vers quoi je tente d'aller avec PhpWiki et son système de template ressemble à quelque chose dans ce genre :

gabarit d'une page type:

<?= Template('top') ?>
<?= $CONTENT ?>
<?= Template('bottom') ?>

Le template top contient par exemple:


L'objectif est d'avoir une base d'éléments autour desquels je peux construire mes propre hiérarchies de div, à la rigueur la façon dont je nomme mes class et id n'a que peu d'importance, une skin complète correspondant à un couple dossier template, +css, il suffit juste d'avoir une liste des éléments disponibles, la liste des templates minimum à créer et les relations d'interdépendances.

Cela va dans le sens d'un simple à personnaliser (aspect) permet d'élargir facilement le nombre de "peaux" disponibles.
je ne suis pas entièrement satisfait du système de PhpWiki qui reste à mon goût encore trop complexe, difficile à appréhender sans y passer du temps.
LL

Pourquoi "encore trop complexe, difficile à appréhender sans y passer du temps" ? Qu'est-ce qui le rendrait plus simple à ton goût sans perdre de son efficacité. Je propose que dans notre réflexion on ne réfléchisse par à la technique pour réaliser le système d'habillage mais uniquement le système fonctionnel permettant de le réaliser. -- CharlesNepote


Propositions concrètes pour WikiNi

Sans aller trop vite, car la réflexion est loin d'être terminée, on peut néanmoins proposer des solutions concrètes à mettre en oeuvre dès maintenant.

1. Transformer le nom du wiki en lien

Avantages :
Inconvénients :

Mais comment gérer un image concomitante ou "à la place de" ?

Solution

Dans /actions/header.php :

Code CSS de la feuille de style par défaut :

2. Sortir l'identification du menu de navigation

Actuellement nous avons :

<div class="header">
<?php echo $this->ComposeLinkToPage?($this->config["root_page"]); ?> ::
<?php echo $this->config["navigation_links"] ? $this->Format($this->config["navigation_links"])." :: \n" : '' ?>
Vous êtes <?php echo $this->Format($this->GetUserName?()); if ($user = $this->GetUser?()) echo ' (<a href="'.$this->config["base_url"] ."ParametresUtilisateur&action=logout\">Déconnexion</a>)\n"; ?>
</div>


Je propose :

<div id="site_nav">
<?php echo $this->config["navigation_links"] ? $this->Format($this->config["navigation_links"])."\n" : '' ?>
</div>

<div id="authent">
Vous êtes <?php echo $this->Format($this->GetUserName?()); if ($user = $this->GetUser?()) echo ' (<a href="'.$this->config["base_url"] ."ParametresUtilisateur&action=logout\">Déconnexion</a>)\n"; ?>
</div>

Notez :

En poussant encore un peu, on peut envisager :

<?php
echo $this->config["navigation_links"]
? "<div id=\"site_nav\">".$this->Format($this->config["navigation_links"])."</div>\n"
: ''
?>

<div id="authent">
Vous êtes <?php echo $this->Format($this->GetUserName?()); if ($user = $this->GetUser?()) echo ' (<a href="'.$this->config["base_url"] ."ParametresUtilisateur&action=logout\">Déconnexion</a>)\n"; ?>
</div>

Notez :
Et je me demande s'il ne faudrait pas intégrer ParametresUtilisateur dans le bloc "authent" ?...
-- CharlesNepote
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]