Voici un message publié sur spip-zone mais qui concerne le core. Il fait suite à une discussion d'une vingtaine de mails sur les mots clés techniques
Cordialement
Joseph
-------- Message original --------
Sujet: Re: à propos des mots clés techniques
Pour: spip-zone-JM9gtpQu/Ho@public.gmane.org
Forums de discussion: gmane.comp.web.spip.zone
Références: <463B1997.5020501@larmarange.net> <f1ffvs$5d0$1@sea.gmane.org> <463B4B8D.9010208@gmail.com>
Serait-ce envisageable de rajouter pour SPIP 1.9.3 au minimum une
variable technique oui/non (sur les groupes de mots) dans le core avec la case à cocher ? (plus un
filtrage natif des boucles MOTS et GROUPES, les mots clés techniques étant par défaut filtrer, sauf si présence d'un critère du type tout_voir).
Cela permettrait de fournir un début d'uniformisation pour les mots clés
techniques. Si l'on désire un fonctionnement plus complexe et un typage
plus poussé des mots clés, il reste les plugins (par exemple mots partout).
Quel intérêt à l'avoir dans le core ? Cela amène une certaine
uniformisation d'un squelette à un autre, uniformisation si on commence
à travailler avec des noisettes.
Lorsque l'on fait un ensemble complet de squelettes, on peut très bien
adopter une convention sur le nom des groupes de mots clés et faire un
filtrage sur l'ensemble des squelettes.
Par contre, si on travaille avec des noisettes que l'on met bout à bout
pour former ces squelettes, on peut envisager une noisette listant les
mots clés associés à un article. Cette noisette de base liste par défaut
tous les mots clés avec une boucle MOTS. Si par la suite, on insère dans
ces squelettes une noisette utilisant un mot clé technique, il faudrait
alors aller modifier la noisette listant les mots clés d'un article.
Par contre, si dans le core on introduit la notion de mots clés
tecniques avec le filtrage associé, alors la noisette de base (qui ne
tient pas compte des mots clés techniques) restera valable puisque le
filtrage sera nativement pris en compte.
D'autre part, si on suppose un site fonctionnant avec un jeu de
squelettes codés sous la forme de plugin. On souhaite changer le style
avec un autre jeu de squelettes également sous forme de plugin (par
exemple lorsqu'on utilise habillage). On devrait pouvoir passer d'un
ensemble de squelettes à un autre puis revenir en arrière si on le
souhaite (distinction entre style et contenu). Si chaque plugin de
squelettes utilise une convention différente de filtrage des mots clés
techniques propre à chaque squelette, alors au changement de squelette
les mots clés techniques du premier squelette, qui étaient filtrés
auparavant ne le seront plus avec ce second squelette. Si, au contraire,
il y a une convention commune liée au core avec l'ajout de la case à
cocher technique sur les groupes de mots clés, alors au changement de
squelette, on aura toujours un filtrage de l'ensemble des mots clés
techniques, à la fois ceux du premier ensemble de squelette et ceux du
second ensemble de squelettes. Les ensembles de squelettes, quant à eux,
peuvent récupérer l'information de leurs propres mots clés techniques en
préfixant les groupes de mots clés tecniques qui les concernent avec le
nom du squelette par exemple. Ainsi, la présence de deux ensembles de
mots clés techniques (certains pour un ensemble de squelettes et
d'autres pour un second ensemble) pourront cohabiter sans problème. Ils
seront dans tous les cas filtrés sur le site public et seuls les mots
clés techniques du squelette actuellement activé seront utilisés. Ainsi,
je peux changer l'ensemble de squelettes que j'utilise sur mon site,
essayer cet ensemble de squelettes pendant quelques mois avant de
choisir de garder ce nouvel ensemble ou de revenir à l'ancien ensemble,
sans avoir besoin de supprimer de suite les mots clés du premier
ensemble. Si à terme je désire ne plus revenir en arrière, il suffira au
webmaster de supprimer les mots clés techniques devenu inutiles. Si, je
désire revenir en arrière, je n'aurai pas perdu toutes les associations
de mots clés techniques du premier squelette.
Il me semble donc pertinent d'envisager, dans le core, un distingo
mots-clés techniques et mots-clés sémantiques avec filtrage sur l'espace
public afin d'avoir un minimum de cohérence entre squelettes et entre
plugin. Par contre, un typage des mots clés dans le cas d'une
utilisation avancée des mots clés, pourrait, quant à elle, être réglé
par un plugin.
Joseph