Mots clefs dans le core - pour une approche générique

Pour mémoire, une réflexion sur la systématisation de l’usage des mots clefs dans SPIP

De : nicolasriq at free.fr
Date : 8 mai 2007 21:50:18 GMT+02:00
À : Spip SPIP
Objet : adaptation des mots clefs dans le core

Bonjour
si cela peut etre utile j’essaye de compiler ici ce que j’ai compris de divers débats croisés concernant les mots clefs, leurs usages possibles, et les adaptations souhaitables sur le core pour ce faire.

L’idée centrale est qu’il ne relève pas du core (bien au contraire il doit tendre au contraire), de chercher à décliner tous les usages possibles, mais aussi qu’il est souhaitable qu’il permette de faire converger les efforts en offrant quelques points communs sur lesquels tous, via les plugins ou le core, peuvent s’accrocher. Une autre idée est qu’il faut éviter autant que faire ce peu de dupliquer les « objets SPIP » (tables et/ou code), sur des concepts « presque pareils ».

Pour ce qui suit je ne parle pas des diverses mises en forme possibles (formulaire, etc ..) et construction du code (jointures, etc ..) qui relèvent des plugins ou du standard du core peut importe, ni des pipelines, mais juste de l’adaptation des « objets SPIP » (tables et champs)

Le cas typique est le sujet des mots clefs et de la gestion des auteurs

Fondamentalement les mots clefs sont consacrés maintenant comme des identifiants qui permettent au commun des mortels de construire des requêtes (jointures et tri) dans, et entres, diverses tables et d’agir sur l’affichage. Avec l’avantage que les mots clefs sont applicables très souplement, sont descriptibles (texte, logo), et disposent déjà de pleins d’outils d’emploi (boucles, core, contribs diverses, documentations). Aussi je propose que le core facilite, officialise, et stabilise, l’extension de leurs usages possibles, soit en vrac et non exhaustives les idées suivantes :

MC1) permettre d’appliquer les mots clefs à tous les objets spip (sauf peut-etre les mots clefs eux-même si c’est trop compliqué) ... peu importe ici les formulaires, qui seront traités selon besoin par chaque plugin, le core ne changeant rien à son standard.

MC2) ajouter un champ qualificatif libre (« attributs » ou n’importe quel nom de champ, peut importe) qui permette de distinguer des grandes familles de comportement, en pouvant associer une description de ce comportement. En standard le core offrirait les familles « sémantique » (le comportement actuel), « technique » (cf les débats récents sur cette liste) ... et pourquoi pas un jour « inscription » (pour traiter un jour des histoires d’acces) .. les plugins rajoutent apres ce qu’ils veulent.

MC3) ajouter un champ "titre_identifiant" (par exemple, pour distinguer de l’id de mysql) qui permette de construire des boucles indépendantes soit de l’id, soit du titre, comme maintenant. Cela faciliterait grandement l’exportation, et aussi par exemple la déclinaison du titre selon le contexte (multilinguisme, localisation dans le site, profil, etc ...) .. j’imagine qu’il faudrait aussi traiter le cas de conflit de dénominations de ces "titre_identifiant".

MC4) éventuellement plus tard, et seulement éventuellement car c’est peut être inutilement compliqué, permettre une arborescence de groupes de mots clefs (avec héritage des propriétes) pour pouvoir affiner des sous-cas de critère de tris. Je ne parle pas du cas des « mots clefs sur les mots clefs » posés de manière libre qui tournerait peut etre à l’usine à gaz.

Pour ce qui est des auteurs on peut imaginer en complément de :

A1) ajouter un statut à "spip_auteurs.statut", par exemple « 7generique », ou une personne soit inscrite dans la base sans aucune conséquence en standard (elle n’apparaît nulle part dans le code standard de SPIP, pas dans la liste des auteurs ou visiteurs du site par exemple). Aux plugins qui le veulent d’appliquer des actions sur ces inscrits comme ils le veulent (exemple : adhérents association, contacts agenda, inscrits spip-liste, etc ...). Le but étant d’avoir un objet spip commun disponible pour tout ce qui traite des personnes.

a quoi cela pourrait servir ? Par exemple pour le cas des plugins d’acces restreints

-  les « zones » (groupes de rubriques, ou groupes d’articles dispersés, ou groupes de forums, ou groupes de documents, ou que sais-je encore) serait défini par la pose de mots clefs (de statut "inscription")

-  les auteurs seraient aussi taggés de ces mots d’inscriptions

-  reste à traiter les cas des « profils d’utilisations » associés (c’est pas encore très clair pour moi) : c’est probablement lié d’une manière ou d’une autre aux possibilités des api d’autorisations définies par le core ... faut-il que ces profils soient aussi taggés des mêmes mots clefs que ci-dessus ?

-  aux plugins ensuite de construire les jointures et formulaires qu’ils veulent (puisque la problématique de l’accès restreint peut être déclinée de nombreuses manières). On pourrait avoir un plugin spécialisé dans l’accès restreint en milieu scolaire, un autre pour des problème d’association, une autre pour des forums, etc ...), voire une même base auteurs utilisées par divers sites spip sous des angles différents (une sorte de LDAP basique)

fin provisoire

@+ NicolasR