Discussion module:Palette de navigation

Discussions sur le fonctionnement du module.

À propos de la syntaxe

Ici, discussions sur la syntaxe utilisée pour peupler le contenu d'une palette de navigation.

La syntaxe actuelle :
Les paramètres généraux :

• titre : le titre de la palette [génère une erreur si absent]
• dessus : la zone de texte "en haut" (après le titre) [optionnel]
• dessous : la zone de texte "en bas" (juste avant la fin) [optionnel]
• image : image à insérer à droite [optionnel]

La partie listes, le module traite N comme un entier valant 1 et augmentant de 1 à chaque fois que l'étape courante a généré un résultat :

• liste N (sans "groupe N") : affiche juste une ligne avec la liste d'éléments
• groupe N et liste N : affiche le nom du groupe suivi de la liste
• groupe N (sans "liste N") : format pour définir un sous-groupe. Dans ce cas le module :
  • considère le préfixe "N."
  • effectue le même traitement qu'indiqué dans "La partie listes…", en ajoutant le préfixe au nombre (N.1, N.2…).

Ce traitement est récursif, c'est-à-dire qu'il s'applique aussi à N.M.1, N.M.2… puis N.M.P.1… chaque fois qu'on est dans la situation d'un groupe sans sa liste.
Note : si on donne le "groupe N", pas la "liste N", mais qu'on ne donne pas de N.1, ne fait rien. C'est a priori une erreur de syntaxe, il faudrait que je génère une erreur explicite dans ce cas.

Ajout : support des "sections" pliables. C'est assez "rugueux" pour le moment. Le principe :

• on ne peut avoir des sections qu'au premier niveau des listes (éléments N et pas N.M ou en dessous).
• pour débuter une section pliante à partir de l'élément N (inclus) il faut ajouter "Section N = titre section"
• la section pliante se poursuit jusqu'à rencontrer une nouvelle section. "Section M = n'importe quoi" → ferme la section ouverte après le niveau M.

Limitations :

• ne permet des sections qu'au niveau de base. On ne peut donc pas faire des sections pliantes à l'intérieur d'un sous-groupe
• l'approche "bascule" (le premier signale le début, le second signale la fin) n'est peut-être pas très intuitif.

À propos du rendu

Ici, discussions à propos des éléments de rendu (bugs, code généré, …).

Note : j'ai viré le "modifier" présent en pleine gauche de la ligne de titre (j'avais un bug). Toutefois je ne sais pas bien sur quoi ce lien doit pointer : modifier le modèle/module ? Lequel ?

Réactions

Bonjour Hexasoft,

Je ne pense pas que ça vienne du module, car ça ne fonctionne pas non plus sur la page de tests de Hlm Z., mais bizarrement la classe fr-collapsible n'a aucun effet; je n'ai pas de boite déroulante avec les liens afficher/masquer. Tu peux confirmer? Pour ce qui est du module en lui-même, est-il possible de récupérer les éléments des listes (*elem 1 *elem2 *elem3) et de les injecter dans un élément li ? Cela permettrait de s'affranchir des blocs div avec les classes palette-liste-simple lh et palette-liste-fils. Faudrait alors adapter la feuille de style à cette modification. Sinon, je pense que c'est très bien parti, très bon boulot. – Je viens en paix, Reptilien.19831209BE1[Bonjour,_✎] 17 avril 2013 à 07:58 (CEST)

Heu, moi ça marche. Tu as bien importé le JS de Hlm Z. (@import "//fr.wikipedia.org/w/index.php?title=Utilisateur:Hlm_Z./Palette_de_navigation/common.css&action=raw&ctype=text/css";) ? Hexasoft (discuter) 17 avril 2013 à 08:04 (CEST)

Le JS (javascript) ? moi je vois du CSS... Je vais regarder à ça. Sinon, j'ai tenté une première approche pour récupérer les éléments d'une liste. C'est une grossière ébauche (je ne connais pas suffisamment le Lua), mais l'idée est là. Reste à l'adapter à ton script pour que la fonction soit récursive. – Je viens en paix, Reptilien.19831209BE1[Bonjour,_✎] 17 avril 2013 à 10:33 (CEST)
----
EDIT: je confirme, les classes citées ci-dessus ne fonctionnent pas chez moi, par contre les classes NavFrame et NavContent fonctionnent correctement. Je continue de chercher. – Je viens en paix, Reptilien.19831209BE1[Bonjour,_✎] 17 avril 2013 à 11:00 (CEST)

Oui, pardon, c'est bien de CSS qu'il s'agit.

Pour le bon/mauvais fonctionnement des entités HTML/CSS je pense qu'il faut discuter technique avec Hlm Z.‎ : pour ma part je n'ai fait que transcrire en Lua la structuration HTML qu'il a créé (et ajouter la gestion Lua des paramètres).

Il est possible que j'ai fait une erreur toutefois, mais en tout cas quand je regarde Discussion utilisateur:Hexasoft/Palette de navigation je ne vois aucun problème d'affichage pour ma part (en tout cas rien de "technique").

Pour l'adaptation des listes peux-tu donner un exemple concret de ce que tu voudrais faire ? Pour l'aspect choix des classes palette-liste-simple lh et palette-liste-fils même réponse que ci-dessus : vois avec Hlm Z.‎, je ne suis qu'un humble pourvoyeur de code Lua. Mais peut-être cherche-tu quelque chose comme Module:Liste éléments (voir la section "Exemples" de la doc, en haut) ? Hexasoft (discuter) 17 avril 2013 à 11:11 (CEST)

OK, je reviens vers toi dès que j'ai vu ça avec Hlm Z. . – Je viens en paix, Reptilien.19831209BE1[Bonjour,_✎] 17 avril 2013 à 11:28 (CEST)

Est-ce que tu as désactivé le gadget activé par défaut newCollapsible ? Il est nécessaire au fonctionnement de fr-collapsible.

Concrètement, c’est quoi l’intérêt de parser manuellement les listes en Lua alors que c’est plus efficace (et probablement plus fiable et supporte listes imbriquées) de passer par le parseur natif de MediaWiki ?

— Ltrl G^☎, le 17 avril 2013 à 16:09 (CEST)

Comme le dit Ltrl G, tu as certainement désactivé le gadget newCollapsible dans tes préférences.

Quelques points :

• Le module génère un div en trop avec un « margin-left: 2em » (juste avant le div « palette-liste-simple lh »), il faudrait que je regarde le code Lua.
• La section ne doit pas être implémenté ainsi (assez complexe), on pourrait imaginer une syntaxe du style :

{{Palette de navigation avec sous-liste
| titre  = Titre
| dessus = Dessus

| section1 = Section 1
| liste1   = Liste 1

| section2 = Section 2
| contenu2 = {{Palette de navigation
 | enfant  = oui

 | groupe1 = Groupe 1
 | liste1  = Liste 1...

| dessous = Dessous
 }}
}}

C'est plus simple et moins couteux àmha. Dans tous les cas, il est préférable d'utiliser {{Palette de navigation}}, {{Palette de navigation avec sous-liste}} c'est juste un modèle de secours pour des palettes de très longues tailles.

• Pour l'histoire du div avec les classes palette-liste-simple lh et palette-liste-fils (décidément, vous l'aimez vraiment pas ce div ), il y a peut-être un moyen de régler ce problème en jouant avec les héritages class/balise directement dans le corps du CSS. Pour l'instant, je ne vois vraiment pas comment faire... Par contre, détourner la syntaxe de MediaWiki pour générer la liste grâce au Lua script, je ne suis pas sûr que ce soit la meilleure façon de procéder.

~Hlm Z. [@] 17 avril 2013 à 18:30 (CEST)

Pour le div en trop avec un « margin-left: 2em » c'est pas dans le code ! C'est mediawiki qui l'insert dans certains cas (que je n'ai pas identifié). Si tu ajoute le paramètre "|raw=oui" tu obtiens la sortie nowiki du modèle. Tu peux ainsi plus facilement analyser le code retourné par le module, pour chercher les problèmes dans le code généré (ce qui simplifie la recherche de la zone fautive dans le code).

Pour les sections, et plus généralement la possibilité d'éclater le code en sous-code, pourquoi pas. J'avais pensé à une option "sous-liste" (mais enfant est très bien). Note : utiliser une sous-liste ça veut forcément dire que la sous-liste est numérotée à partir de 1, quelque soit l'environnement dans lequel on la met. C'est l'effet voulu ?

D'ailleurs tu aurais des exemples réels de palettes complexes (mettant en œuvre les sous-groupes et les sous-sections pliantes) histoire que je vois un peu mieux ?

Pour le div des palette-liste-simple lh et palette-liste-fils perso moi ça me fait ni chaud ni froid . Hexasoft (discuter) 17 avril 2013 à 19:21 (CEST)

En effet, le gadget newCollapsible était bien désactivé, je me rappelle pourquoi maintenant. @ Ltrl G: il est vrai qu'il vaut mieux éviter de parser manuellement les listes en Lua, c'était une proposition pour tenter de résoudre le problème de la syntaxe de Hlm Z. telle que | liste1 = * elem1 * elem2 * elem3. Je pense que Hlm Z. a raison quand il dit qu'on doit pouvoir régler le problème « en jouant avec les héritages class/balise directement dans le corps du CSS ». Je m'y appliquerai dès que j'aurai un peu de temps libre. – Je viens en paix, Reptilien.19831209BE1[Bonjour,_✎] 17 avril 2013 à 22:35 (CEST)

Hlm Z. : à part la partie "section", est-ce que la version actuelle convient ? Au moins sur le résultat, et en faisant abstraction de la possibilité d'inclure des sous-tables.

Histoire d'avancer sur les différents points.

Pour l'inclusion de sous-partie je vais regarder. Est-ce que le principe d'avoir un "contenu=…" (à la place d'un "liste=") convient pour signifier une inclusion de sous-liste ?

Pour les sections, histoire de préciser aussi : qu'est-ce qui différencie coté code généré une sous-boîte et une boîte ? Support du dessus/dessous ? Pas le div principal ? Hexasoft (discuter) 17 avril 2013 à 22:44 (CEST)

ParserFunctions : Utilisateur:Hlm Z./Palette de navigation/Bacasable.

Lua script : Utilisateur:Hlm Z./Palette de navigation/Bacasable 2.

Tout à l'air de bien fonctionner (à part le margin-left: 2em, mais c'est pas urgent). Pour les sections, « |enfant=oui » aura pour effet de contenir tout ce qui se trouve entre les ul principales (avec imageX donc), pas de dessus-dessous. Cordialement, ~Hlm Z. [@] 18 avril 2013 à 00:03 (CEST)

Ok, je regarde ça. Note : il y a toutefois un chtit problème : les listes "simples", centrées, sont légèrement décalées vers la droite. On le voit en comparant la position du "Liste 1" par rapport à "dessus" par exemple, qui lui est centré. Je regarde aussi. Hexasoft (discuter) 18 avril 2013 à 08:02 (CEST)

J'ai normalement corrigé le margin-left: 2em (un ul en trop semble-t-il, qui se retrouve transformé par mediawiki en margin-machine). Ça corrige au passage le décalage par rapport au centre.

Par contre la version "modèle" semble insérer un petit décalage (voir les items centrés à gauche), ce qui est visuellement mieux. Je vais regarder.

Je vais voir pour ajouter l'option "enfant" histoire de préparer le terrain pour les sous-inclusions. Hexasoft (discuter) 18 avril 2013 à 11:39 (CEST)

La version modèle ajoute aux balises « ul » (liste) et « p » (paragraphe) un margin de 2px à gauche, il y a en effet 2 cas possibles :

• Soit « Liste 1 » est un élément de la liste :

| groupe1 = Groupe 1
| liste1  =
* Liste 1

• Soit « Liste 1 » est un simple paragraphe :

| groupe1 = Groupe 1
| liste1  = Liste 1

Or pour le second, Lua ne génère pas les balises « p » attendues. Dans /Ligne, je fais en sorte que le paramètre « |liste= » soit en début de ligne :

<div class="palette-liste lh" style="background:red;">
{{{liste}}} //Si c'est une liste, pas de problème, sinon c'est un paragraphe
</div>

Je me sers de cette technique pour générer ce fameux « margin de 2px », mais on peut très bien procéder autrement en Lua. On doit souvent choisir entre MediaWiki et Lua, c'est assez contraignant... ~Hlm Z. [@] 18 avril 2013 à 12:28 (CEST)

Nan, ce n'est pas un « choix » entre Lua et MediaWiki : si tu fais la même sortie dans l'un ou dans l'autre, tu obtiens le même résultat (la différence notable étant sur les modèle : par défaut la sortie de Lua ne passe pas par le remplacement des modèles par leur contenu).

Dans ton exemple, je traite ça en ajoutant un retour à la ligne si "liste1" commence par un "*". Mais je peux très bien l'ajouter systématiquement si ça ne fait pas d'effet de bord. Hexasoft (discuter) 18 avril 2013 à 12:46 (CEST)

Je découpe, pour séparer les discussions…

Cas triviaux (et margin 2px)

J'ai ajouté deux exemples dans les cas triviaux : la même chose que l'ancien #1 et #2 mais avec une vraie liste (* el1\n* el2\n* el3) pour tester.

Actuellement la sortie HTML est strictement identique entre la version modèle et la version lua (à part le "modifier" en haut à gauche, qu'il faudra ajouter plus tard), en tout cas sur les 4 premières palettes présentées.

Gestion de sous-palettes (sous-groupe+contenu)

Je vais faire des tests, mais je pense qu'il y a confusion sur les termes. Pour moi il y a deux fonctionnalités différentes :

• pouvoir inclure une palette dans une palette (ce que moi j'appelle "sous-palette")
• pouvoir avoir des sous-parties de la palette qui se plient/déplient (ce que moi j'appelle "section").

Ici je parle du premier point.
J'ai intégré une option "enfant", qui actuellement désactive l'ajout de l'entête et de la fin. J'ai quelques réglages à faire mais ça devrait aller vite. L'idée est bien de pouvoir insérer un appel à "palette" en tant que contenu à donner à un champs "liste", n'est-ce pas ?

Il y a bien confusion. Cette syntaxe :

{{Palette de navigation avec sous-liste
| titre  = Titre
| dessus = Dessus

| section1 = Section 1
| liste1   = Liste 1

| section2 = Section 2
| contenu2 = {{Palette de navigation
 | enfant  = oui

 | groupe1 = Groupe 1
 | liste1  = Liste 1...

| dessous = Dessous
 }}
}}

représente ton deuxième point (section). Pouvoir inclure une palette dans une palette, c'est une approche à laquelle je n'ai pas encore réfléchi (on supprime {{Palette}} du coup ?). ~Hlm Z. [@] 18 avril 2013 à 13:46 (CEST)

Heu, je sais pas .

Disons que je n'ai normalement pas besoin de faire de distinction entre "Palette de navigation", "Palette de navigation avec sous-liste" et "Palette de navigation sous-groupe", coté module.

Un "sous-groupe" n'est qu'un "Palette de navigation" sans les entêtes. Un "sous-liste" n'est que la possibilité d'ajouter autour de certaines (toutes ?) parties une boîte déroulante.

Donc ici je parle de ce que tu appelles "sous-groupe". Sauf erreur de ma part l'option "enfant" devrait permettre d'utiliser le même modèle (la même fonction du module) pour faire la palette "principale" ou pour construire des sous-parties de cette palette. Hexasoft (discuter) 18 avril 2013 à 14:00 (CEST)

Je comprends bien, mais le but est bien de séparer {{Palette de navigation}} et {{Palette de navigation avec sous-liste}} car il ne faut pas abuser de ce dernier. 2 modèles différents pour un seul module. ~Hlm Z. [@] 18 avril 2013 à 14:10 (CEST)

Pas de soucis de ce coté-là. Plusieurs modèles peuvent référencer la même fonction Hexasoft (discuter) 18 avril 2013 à 14:14 (CEST)

Gestion des sections (sous-parties pliables)

De ce que j'ai vu c'est en fait bien plus simple que ce que j'ai fait : on ne peut faire une sous-partie que sur une seule "entrée". Après cette seule entrée peut contenir plusieurs éléments mais en passant par une sous-palette. C'est bien ça ?

Voir #Gestion de sous-palettes (sous-groupe+contenu).

Palette de navigation avec sous-liste

Section « simple » avec listes d'éléments (ex. {{Palette Personnalité de l'année}}) :

{{Palette de navigation avec sous-liste
| titre  = Titre
| dessus = Dessus

| section1 = Section 1
| liste1   = Liste 1

| section2 = Section 2
| liste2   = Liste 2

...
}}

Section avec comme contenu le « corps d'une palette fils » (ex. {{Palette Lois de probabilités}}, {{Palette Cetacea}}, {{Palette Troubles mentaux et du comportement}}) :

{{Palette de navigation avec sous-liste
| titre  = Titre
| dessus = Dessus

| section1 = Section 1
| contenu1 = {{Palette de navigation
 | enfant  = oui

 | groupe1 = Groupe 1
 | liste1  = Liste 1
 }}

| section2 = Section 2
| contenu2 = {{Palette de navigation
 | enfant  = oui

 | groupe1 = Groupe 1
 | liste1  = Liste 1

 | groupe2 = Groupe 2
 | liste2  = Liste 2
 }}

...

| dessous = Dessous
}}

En espérant avoir répondu à la question (« numérotée à partir de 1 »). ~Hlm Z. [@] 17 avril 2013 à 20:07 (CEST)

Que j'suis bête : la numérotation qu'on voit, c'est le nom des groupes dans les exemples . On met bien ce qu'on veut ! Hexasoft (discuter) 17 avril 2013 à 20:22 (CEST)

J'ai retiré la forme « liste 1 » et « Liste 1 » : c'est une simple question de maintenance. Ça va surement créer des problèmes à l'avenir et je suis pas tellement fan des alias de paramètres. ~Hlm Z. [@] 17 avril 2013 à 21:03 (CEST)

Détails divers

Quelques trucs qui peuvent améliorer l'aspect, que tu as peut-être prévu :

• mettre des couleurs par défaut moins violentes (je peux facilement ajouter le support des options de couleur)
• permettre l'alternance des couleurs ? (comme c'est dans les palettes actuelles)
• prévoir de pouvoir apparaître fermé ?

Hexasoft (discuter) 18 avril 2013 à 16:21 (CEST)

Tu n'aimes pas mes zolies couleurs ? Plus sérieusement, j'ai ajouté deux nouvelles classes CSS : palette-liste-pair et palette-liste-simple-pair (cf. modification). Il ne reste plus qu'à alterner impair (palette-liste) / pair (palette-liste-pair). Pour limiter l'effet « sapin de Noël », seules les couleurs des groupes/bannières/titres peuvent être modifiées (le blanc/gris des listes étant neutre). Il faudra par la suite se demander si oui ou non on garde certains paramètres. ~Hlm Z. [@] 18 avril 2013 à 17:15 (CEST)

Super. Note : le pair/impair ne peut se faire qu'au sein d'une même entité. Quand on utilise une sous-palette l'alternance repart "au début". Toutefois ça doit déjà être comme ça actuellement (avec les modèles). Il serait possible d'assurer l'alternance en ajoutant un paramètre "départ alternance" (passé depuis "le dessus") mais c'est peut-être se compliquer la vie pour rien :) Hexasoft (discuter) 18 avril 2013 à 22:44 (CEST)

Ajouté. Question : pas d'alternance pour les éléments "simples" (palette-liste-simple) ?

Pour les options diverses et variées je pense que de nombreuses ne sont pas utiles dans un premier temps (jouer avec les couleurs c'est pas de la fonctionnalité, c'est du tuning ). Hexasoft (discuter) 18 avril 2013 à 22:57 (CEST)

Inutile pour les sous-palettes. Cette alternance doit se faire pour les listes simples et listes avec groupes seulement (comme avant quoi). Pour la question : « j'ai ajouté deux nouvelles classes CSS : palette-liste-pair et palette-liste-simple-pair » . ~Hlm Z. [@] 18 avril 2013 à 23:40 (CEST)

Par contre, il y a quelques trucs qui sont cassés chez moi (Bacasable 2). ~Hlm Z. [@] 18 avril 2013 à 23:44 (CEST)

J'ai normalement corrigé les trucs cassés.

J'ai fait de la mise au propre pour pouvoir gérer les paramètres variés de façon simple (quand on a 4-5 paramètres on fait à la main, après on automatise ).

Note : je vais être absent durant une semaine (vacances).

Question purement théorique : que se passe-t-il si je mets des sous-items dans les items d'une listes ? (des * el1\n** el1.1\n**el1.2…)

Truc pratique : j'ai l'impression qu'on doit pouvoir donner directement la sortie de {{liste éléments}} dans le module (ça n'a pas d'intérêt mais ça permet de rester compatible). À vérifier.

Question sur palette/meta palette : quand une meta-palette est dans une palette il y a le paramètre "parent=bandeau". En pratique comme tu peux le voir en haut de Discussion utilisateur:Hexasoft/Palette de navigation ma version (la première, à comparer à la seconde) fonctionne bien en étant appelé depuis {{palette}} mais les traits de séparation ne sont pas les mêmes : il y a dans ma version un trait additionnel autour et − plus pénible − entre les éléments. Tu saurais ce qui fait ça ?

Hexasoft (discuter) 19 avril 2013 à 12:34 (CEST)

Quelques points :

• L'alternance des lignes pairs n'est pas optimale (il faudrait gérer les cas des sous-groupes et des lignes simples).
• À propos des sections, est-il possible que ses paramètres soient seulement compatibles dans le modèle {{Palette de navigation avec sous-liste}} ? (une fois encore, il ne faut pas abuser de ce modèle).
• Logiquement, avec la structure que j'ai faite, plus besoin de {{Palette}}. Mais on pourrait envisager un truc comme : si les arguments de {{Palette}} sont supérieurs à 5, on enroule le tout dans une palette père.
• La classe lh est compatible avec les sous-listes : en gros * el1\n** el1.1\n**el1.2, ça marche parfaitement bien (à par sur IE<=8... mais c'est un autre problème).

Bonne vacances . ~Hlm Z. [@] 19 avril 2013 à 13:47 (CEST)

Demain, seulement, les vacances… :)

Pour la classe lh : ok (c'était juste de la curiosité )

Pour l'alternance oui. C'est ce que j'évoquais (mal) plus haut : dans un sous-groupe généré à part on ne connait pas le "comptage pair/impair" du dessus. On peut envisager un paramètre pour ça.

Pour Palette oui je vois ce que tu veux dire. Toutefois il me semble que si on donne un moyen de changer les modèles sans toucher aux syntaxes existantes, tout en permettant ensuite d'évoluer vers une syntaxe plus simple, ça sera plus facile à mettre en œuvre (et à accepter). Exemple : pouvoir laisser les {{liste éléments}} en place et les remplacer ultérieurement par des "*el1\n*el2…" apporterait de la souplesse de migration, non ?

Pour les sections : peux-tu préciser, je n'ai pas bien compris ? Note que je n'ai pas re-travaillé sur les sections pour le moment, hein, j'ai juste travaillé sur l'aspect (éléments de classe/style) et sur la possibilité d'utiliser des éléments générés par la fonction comme entrée dans un sous-groupe.

Hexasoft (discuter) 19 avril 2013 à 14:03 (CEST)

Si l’alternance ne se fait pas automatiquement en Lua, cela risque d'être très contraignant. Une solution serait de déclarer une variable n, d’incrémenter à chaque fois cette variable lorsqu'il existe une nouvelle liste/groupe, puis de faire le test de parité « n%2==0 » (c'est peut-être le paramètre que tu évoques plus haut).

Pour les sections, le modèle {{Palette de navigation}} sera capable d'afficher le titre, image, dessus/dessous, les listes/groupes mais pas des sections/contenus. Ces paramètres (sections/contenus) seront propres à {{Palette de navigation avec sous-liste}}. Cordialement, ~Hlm Z. [@] 19 avril 2013 à 14:26 (CEST)

Points à corriger

Après mûre réflexion, plusieurs points sont à noter :

• Pour l'alternance des lignes, je crois qu'il est vraiment primordial de trouver une solution automatique, ne dépendant d'aucun paramètre dans les palettes.
• Pour le paramètre « modifier » à gauche, il doit pointer vers le nom de la palette en question (ex. {{Palette Système solaire}}).
• Pour la fermeture/ouverture des palettes, voici les différentes classes à utiliser :

Paramètre	Classe	Argument	Note
état	fr-collapsed	Aucun (par défaut)	Argument actuel : autocollapsed
	collapsed fr-collapsed	« fermé »	Argument actuel : collapsed
	Aucune	« ouvert »	Argument actuel : uncollapsed

On pourrait également envisager un autre argument (« |état = inactif ») pour désactiver l'affichage du masquer/afficher (de même, il faudrait envisager un paramètre pour désactiver le « modifier » à gauche). Cela pourrait être utile pour des palettes annexes.

• Pour les sections, il faudrait créer une méthode exportable dédiée au modèle {{Palette de navigation avec section}}, rendant les sections inutilisables au modèle {{Palette de navigation}} (c'est le but recherché).

Voilà, c'est à peu près tout. Note : dans le module, à quoi sert « palette-fille » ? Cordialement, ~Hlm Z. [@] 1 mai 2013 à 13:10 (CEST)

Hello,

désolé, je suis de retour mais avec une cote cassée, je suis moyennement fonctionnel . J'ai bien l'intention de reprendre tout ça sous peu. Hexasoft (discuter) 1 mai 2013 à 14:02 (CEST)

Prompt rétablissement. Cordialement, ~Hlm Z. [@] 1 mai 2013 à 17:06 (CEST)

Après une longue méditation, je propose une autre implémentation pour les sections, la syntaxe suivante serait plus appropriée :

{{Palette de navigation
| modèle = {{subst:PAGENAME}}
| titre  = 

| dessus = 

| section1 = 
| liste1   = 

| section2 = 
 | groupe2.1 = 
 | liste2.1  = 

 | groupe2.2 = 
 | liste2.2  = 

| section3 = 
| liste3   = 

| dessous = 
}}

Du coup, une syntaxe du style

{{Palette de navigation
| modèle = {{subst:PAGENAME}}
| titre  = 

| dessus = 

| groupe1 = 
| liste1  = 

| section2 = 
 | groupe2.1 = 
 | liste2.1  = 

 | groupe2.2 = 
 | liste2.2  = 

| groupe3 = 
| liste3  = 

| dessous = 
}}

mélangeant groupe et section serait fortement déconseillée. Cordialement, ~Hlm Z. [@] 31 mai 2013 à 16:37 (CEST)

Logiques (l’implémentation et le fait de déconseiller le mélange), je suis plutôt pour cette version.

Mais déconseiller est peut-être un peu faible… on doit pouvoir l’empêcher sans trop de problème, non (affichage d’une erreur si cohabitation de groupes de premier niveau et de sections) ? Ça reste à voir « avec la communauté » : souhaite-t-on que ce soit possible ou non ?

La version par sous-modèle avait au moins un avantage (bien que je sois contre), c’est la possibilité d’inclure une même section dans plusieurs palettes… je ne sais pas vraiment si ce n’est pas un usage négligeable, mais ça pourrait exister.

— Ltrl G^☎, le 31 mai 2013 à 20:20 (CEST)

Histoire d'être à jour : les problèmes cités ci-dessus sont résolus. J'ai réécrit le module et créé Module:Palette de navigation/Bac à sable. La suite se trouvera sur Discussion Projet:Palette. Hlm Z. [@] 19 août 2013 à 21:21 (CEST)

De gauche à droite?

Actuellement les titres ed section ont une logique latéralisée en allant de gauche à droite.

A gauche, le titre, à droite, les possibilités wiki, telles que la modification/l'évolution du contenu.

Pour la palette, les boutons l v m d, pour visualiser, disuter et modifier le modèle sont à gacuhe, alors que le bouton affichier/dérouler/masquer est à droite.

La latéralisation est donc inverse: les élements d'utilisation et de lecture à droite, les élements liés à la modification à gauche!

Pourquoi cette absence de cohérence?