[spip-dev] spip 3 - groupes de groupes de mots-cles / mots sur mots

Bonjour tout le monde,

Question à propos de SPIP 3, dont je viens d’installer une instance pour la première fois (wouaaaaaaaaaaaaaaaa :slight_smile: ).

Ces dernières années, j’ai été amené à utiliser à plusieurs reprises différents plugins me permettant de créer une certaine hiérarchie dans les mots-clés ou les groupes de mots-clés.

J’ai principalement utilisé http://www.spip-contrib.net/mot-clefs-partout (uniquement pour la partie me permettant de créer des sous-groupes de mots), et j’ai également chipoté avec http://plugins.spip.net/momo.html ( principe similaire mais différent : possibilité d’assigner des mots-clés à d’autres mots-clés). Si je ne me trompe pas, ces plugins ne fonctionnent pas (encore) avec la V3. Selon ce que mon ami google a pu me dire à ce sujet, adapter momo à la V3 ne devrait pas être trop compliqué (?), mais qq’un aurait-il une solution viable pour dupliquer la fonctionnalité « sous-groupes de mots-clés » dans spip 3 ?

Merci à tous !

Alex Gomes

IT Unit

ITUC International Trade Union Confederation

Boulevard du Roi Albert II 5, B 1, B-1210 Brussels, Belgium
Tel: 32(0)2 224 0211 Direct: (0)2 224 0281

PS : oui, je connais polyhiérarchie, et malheureusement, il ne remplit pas mes besoins particuliers…

(En marge de la première question, ça m'intéresse que tu décrives tes besoins particuliers pour savoir ce qui manquerait à Polyhiérarchie.)

Avec plaisir - ca devra peut-être attendre jusqu'à vendredi, vu que je suis en déplacement demain ( et que je me taille du bureau dans 5 min!).
En préambule, je dirai que c'est une question de méthode de travail et philosophie de gestion de contenu plutôt qu'un commentaire négatif sur la qualité intrinsèque de Polyhiérarchie ou sur un manque de fonctionnalités de celui-ci. Je pense honnêtement que le plugin fait très bien ce qu'on lui demande de faire; seulement, je ne veux pas faire comme ça...
J'écrirai une réponse plus fouillée demain / vendredi, promis!

Alex

Donc, vu que j'ai un peu de temps entre 2 tables rondes du CMSday, je te fais une réponse plus complète. (Note: je poste ceci après mon retour a Bruxelles, vu que CMSday n'avait pas jugé opportun de mettre le réseau wifi de la salle en accès public...)

Pourquoi j'ai besoin d'arborescence de mots-clés et/ou de pouvoir mettre des mots sur les mots ? Cas pratique: continent/ sous-continent / pays + groupes de pays arbitraires ("francophonie", "commonwealth", "pays où les dirigeants portent des chaussettes bleues"). Un système de mots-clés sur mots-clés me permet de définir une fois pour toutes ces liens, et ne demande à l'utilisateur que de sélectionner un pays dans une drop-down list pour affecter implicitement à son article tout un tas d'information.

Mais mais mais ! On peut aussi faire ça en liant des rubriques avec Polyhiérarchie !!

OK, mais :
Sur plusieurs projets, j’ai séparé la structure par rubriques de la partie privée de celle du front-end, qui se base exclusivement sur des mots-clés. Ceci me permet de gérer plus facilement mes utilisateurs internes : les plus bordéliques (60%) des auteurs sont admins restreints de leur propre "département" dans le back-end, qui est vaguement structuré suivant l'organisation interne de la boite, alors que le front-end est structuré selon les besoins des utilisateurs lambda, qui se fichent éperdument du fait que le sujet X est géré par la personne Y dans le département Z, ou parfois par plusieurs personnes appartenant à des départements différents. Cette méthode me permet d’éviter que les "vilains" utilisateurs internes ne tentent de répliquer leur structure personnelle de travail dans la partie publique du site. Cela me permet également de les pousser à passer quelques secondes à catégoriser proprement leur information, vu que s'ils ne taggent pas leurs articles, ceux-ci n'apparaissent nulle part sur le site public.
L'utilisation des mots-clés me permet de séparer les tags en groupes sémantiques (pays, type de contenu, "sujet principal", tags de description de contenu du texte, etc) distincts dans l’interface de création/édition d’un article, et me permet aussi d’utiliser les fonctionnalités natives telles que « un seul mot de ce groupe » ou « groupe important », ou des plugins tels que motus pour cacher certains groupes de mots-clés à certains auteurs.

Similairement, je dois parfois créer des structures hiérarchiques (en arbre) de mots-clés dans laquelle j'ai besoin de mettre les mots-clés dans des groupes et sous-groupes qui, eux, doivent être non-sélectionnables (exemple : groupe "responsable des violations des droits syndicaux" > sous-groupe "Etat" > mots-clés "Etat en tant qu'employeur", "Etat au pdv légal", etc). Et encore une fois, l’auteur choisit simplement le mot-clé kivabien dans une drop-down list (qui montre la structure groupes->sous-groupes->mots) en 2 clicks.

Évidemment, ce ne sont que quelques exemples pris a brûle-pourpoint, et je reste persuadé que Polyhiérarchie fonctionne parfaitement pour des besoins différents des miens. Est-ce que mon avis vous semble logique/viable, ou vous pensez que je me plante ?

Pour la petite histoire, j'ai testé et fait tester Polyhiérarchie sur un autre projet : mes collègues trouvaient le sélecteur de rubriques un peu longuet à utiliser lorsqu'il leur fallait ajouter plus de deux ou trois rubriques. De plus, ils comprennent immédiatement le principe des mots-clés, alors que la polyhiérarchie de rubriques/articles leur demande une gymnastique intellectuelle qui représente un challenge plus important pour certains. Mais j'imagine que ceci vient aussi de leurs habitudes, et des miennes.

Je pourrais trouver un budget en interne pour subventionner le développement d'une solution efficace, pérenne et extensible... Mais vu le créneau de ma boîte (syndicats internationaux), ledit budget ne sera sans doute pas très impressionnant. Quelqu'un a envie de mordre à l'hameçon? :slight_smile: Il est bien clair que le produit du développement serait mis à disposition de la communauté. Histoire de ne pas polluer la liste, j'imagine qu'il vaudrait mieux que les éventuelles propositions se fassent par message privé.

Bonne nuit à tous!
Alex

(Cette discussion aurait dû se dérouler sur spip-zone, vu qu'on parle de plugins.)

Polyhiérarchie fonctionne bien, mais c'est "juste" un ajout basique d'une table de liaison générique pour mettre plusieurs rubriques : il n'y a (pour l'instant en tout cas) aucune option, aucune *fonctionnalité* supplémentaire, qui seraient configurables pour les rubriques. C'est pour ça que je demandais tes manques.

Et ta réponse c'est ce que je retrouve souvent quand je demande les manques dans le domaine du classement : pouvoir configurer plus finement qui peut assigner quoi dans telle rubrique ou telle branche.

Ce qui revient à retrouver le comportement des groupes :
"qui peut utiliser les rubriques de cette branche"
"sur quels objets peut-on assigner les rubriques de cette branche"
"obligatoire ou pas"
"une seule rubrique dans cette branche".

Et j'en rajouterai un : "Interdire la sélection de cette rubrique" qui permet alors de ne l'utiliser que comme conteneur.
Avec ces 5 options, ça permet tout ce que permettaient les mots, mais en mieux puisque hiérarchique.

Ces fonctionnalités ne seraient pas spécialement à implémenter dans Polyhiérarhie, afin que le code reste simple, et l'interface aussi quand on ne veut pas plus complexe. Mais ça pourrait être un autre plugin qui ajoute toutes ces configurations.

Après, ce débat a eu lieu mille fois : que *techniquement* on utilise dans la base de données la table des mots-clés ou la table des rubriques pour implémenter tout ça, ce n'est pas le plus important d'après moi !
Ce qui m'intéresse c'est que "rubrique principale" ou "mots-clés multiples", dans tous les cas on parle de *classement* et que je ne vois pas l'intérêt d'utiliser plusieurs objets éditoriaux différents pour faire la même besogne : classer.

Il est mieux pour les développeurs de n'avoir à maintenir qu'une seule API, que l'on étend au besoin, y compris en n'ayant pas forcément la même *interface utilisateur* suivant la manière de classer.

Bon, c'est un peu du vent pour l'instant, mais c'est un sujet qui me trotte dans la tête régulièrement depuis longtemps, donc c'est toujours bien de le noter quelque part. :slight_smile:

(Cette discussion aurait dû se dérouler sur spip-zone, vu qu'on parle de
plugins.)

Polyhiérarchie fonctionne bien, mais c'est "juste" un ajout basique
d'une table de liaison générique pour mettre plusieurs rubriques : il
n'y a (pour l'instant en tout cas) aucune option, aucune
*fonctionnalité* supplémentaire, qui seraient configurables pour les
rubriques. C'est pour ça que je demandais tes manques.

Et ta réponse c'est ce que je retrouve souvent quand je demande les
manques dans le domaine du classement : pouvoir configurer plus finement
qui peut assigner quoi dans telle rubrique ou telle branche.

Ce qui revient à retrouver le comportement des groupes :
"qui peut utiliser les rubriques de cette branche"
"sur quels objets peut-on assigner les rubriques de cette branche"
"obligatoire ou pas"
"une seule rubrique dans cette branche".

Et j'en rajouterai un : "Interdire la sélection de cette rubrique" qui
permet alors de ne l'utiliser que comme conteneur.
Avec ces 5 options, ça permet tout ce que permettaient les mots, mais en
mieux puisque hiérarchique.

Ces fonctionnalités ne seraient pas spécialement à implémenter dans
Polyhiérarhie, afin que le code reste simple, et l'interface aussi quand
on ne veut pas plus complexe. Mais ça pourrait être un autre plugin qui
ajoute toutes ces configurations.

Après, ce débat a eu lieu mille fois : que *techniquement* on utilise
dans la base de données la table des mots-clés ou la table des rubriques
pour implémenter tout ça, ce n'est pas le plus important d'après moi !
Ce qui m'intéresse c'est que "rubrique principale" ou "mots-clés
multiples", dans tous les cas on parle de *classement* et que je ne vois
pas l'intérêt d'utiliser plusieurs objets éditoriaux différents pour
faire la même besogne : classer.

Juste une petite différence, qui fonde le choix :
- la règle de base de SPIP est la "hiérarchie unique" des Rubriques
  (analogue au systèmes de BdD hierarchiques cf IMS/DL/1 du XX°siècle)
- la gestion des mots-clés correspond à des index supplémentaires
   et effectivement, il est tentant d'y adjoindre une gestion par
   groupes de groupes (ce qui correspond juste à :
   => soit gérer la table GROUPES_MOTS (relativement à MOTS )
       comme est gérée RUBRIQUES par rapport à ARTICLES
   => soit introduire le fonctionnement (reflexif) de bouclage
       directement dans la table MOTS

Mais la complexité possible (penser à MomO par exemple)
et le problème de la detection des boucles,
cela peut demander unpeu de reflexion pour choisir..

@+