[SPIP Zone] un seul plugin a tout faire pour les mots clefs ?

Archives Zone
1

Salut,
bon le sujet a été abordé plusieurs fois mais c'est pour le mettre a plat une bonne fois pour toute.
serait-il interessant ( ma réponse est oui) que l'on regroupe les plugins mots techniques et mots partout arbo ?

Merci,

ps: je travaille actuellement a rénover le code de mots_partout_arbo, et a ajouter une nouvelle fonctionnalité :
gérer une arborescence sur les mots clefs ( un mots peut etre parent d'un autre , etc ... )
on pourrait avoir donc l'arborescence avec les groupes et les mots.

2

Le 14 sept. 07 à 10:11, Yoann NOGUES a écrit :

Salut,
bon le sujet a été abordé plusieurs fois mais c'est pour le mettre a
plat une bonne fois pour toute.
serait-il interessant ( ma réponse est oui) que l'on regroupe les
plugins mots techniques et mots partout arbo ?

Merci,

ps: je travaille actuellement a rénover le code de mots_partout_arbo, et
a ajouter une nouvelle fonctionnalité :
gérer une arborescence sur les mots clefs ( un mots peut etre parent
d'un autre , etc ... )
on pourrait avoir donc l'arborescence avec les groupes et les mots.

Pour moi la réponse est oui aussi.

pierre

3

> serait-il interessant ( ma réponse est oui) que l'on regroupe les
> plugins mots techniques et mots partout arbo ?

à priori non, car mots techniques a vocation à entrer dans le core,
alors que les mots arborescents probablement pas

-- Fil

4

* Fil tapuscrivait, le 14/09/2007 10:23:

serait-il interessant ( ma réponse est oui) que l'on regroupe les
plugins mots techniques et mots partout arbo ?

à priori non, car mots techniques a vocation à entrer dans le core,
alors que les mots arborescents probablement pas

Par contre, que les mots arborescent puissent s'adjoindre aux mots technique sans surcharge du core (donc avec les bons points d'entrées), ça serait très souhaitable.

--
RealET

5

RealET a écrit :

* Fil tapuscrivait, le 14/09/2007 10:23:
  

serait-il interessant ( ma réponse est oui) que l'on regroupe les
plugins mots techniques et mots partout arbo ?
        

à priori non, car mots techniques a vocation à entrer dans le core,
alors que les mots arborescents probablement pas
    

Par contre, que les mots arborescent puissent s'adjoindre aux mots technique sans surcharge du core (donc avec les bons points d'entrées), ça serait très souhaitable.

oui clairement.
mais il faudrait alors que mots_techniques reprenne la gestion "generique" des mots clés de mots_partout et mette les points d'entrée ou il faut.
mots_partout serait alors une simple extension des mots clés.

Mais le probleme, encore une fois, c'est les interfaces d'administration.
Pour l'instant, l'onglet dans la config qui s'appuie sur un gros tableau de parametrage (mélangeant beaucoup de choses...), c'est bof...

sinon, pour l'arborescence de mots, c'est quoi l'idée ?
un id_parent au niveau du mot ?

@++

6

Yoann NOGUES a écrit :

on pourrait avoir donc l'arborescence avec les groupes et les mots.

Alors arborescence sur les mots et/ou sur les groupes ? Telle est la question.

Chez nos amis de Drupal, les pros de la taxonomie, on procède ainsi :

Le groupe de mot-clés est comme dans SPIP, il a un nom et permet de définir les propriétés des mots clés qu'il contient (afficher sur les articles, par les auteurs ou pas etc...)

Ensuite dedans il y a des mots clés, qui peuvent, éventuellement, avoir pour parent un autre mot clé du groupe -> arborescence de mots dans le groupe.

Ca permet à drupal de gérer avec le meme système de "category" les mots clés et les rubriques.

Je trouve ca assez carré. Et je crois que ca revient à coller un id_parent facultatif aux mots-clés.

L'autre possibilité est de permettre de mettre des sous-groupes dans des groupes de mots, la aussi on créé une arborescence mais différente.

Personellement ca me parait plus abstrait, et l'avantage par rapport à la solution précédente ne m'est pas clair.

J'aime assez la séparation proposée par la solution 1 :

groupe = définission des propriétés
mots = taxonomie, qualification du contenu.

Mais je ne suis pas du tout expert en mots clés, donc je me contente d'atiser le débat en répétant ce que j'ai observé chez drupal, dont la solution est proche de spip, avis aux experts

BoOz, demain j'essaie joomla :stuck_out_tongue:

7

BoOz a écrit :

Yoann NOGUES a écrit :

on pourrait avoir donc l'arborescence avec les groupes et les mots.

Alors arborescence sur les mots et/ou sur les groupes ? Telle est la question.

Le fonctionnement actuel : arborescence de groupes de mots , et chaque groupe contient des mots
Je suis partisan pour ce principe d'arborescence des mots.

toute fois l'arborescence des groupes me parait intéressante (mais pas indispensable) , pour pouvoir conserver des propriétés différentes (grace aux groupes) sur tous les niveaux de l'arborescence...

vu que l'arborescence sur les groupes est déjà faites , je propose de la laissé.
et je me propose de rajouter l'arborescence sur les mots directement.

dans la structuration des données :
sur les groupes :
id_groupe : comme avant
id_parent : id du groupe parent

sur les mots:
id_groupe: id du groupe parent ( directement ) ou id du secteur de l'arborescence
id_parent : id du mot parent
(id_secteur) : ben ca dépend si on distingue le id_groupe du id_secteur et si oui , on met 0 dans id_groupe quand on id_secteur ? mais bon ca complque un peu les choses ...

et vous ?

8

BoOz a écrit :

Yoann NOGUES a écrit :

on pourrait avoir donc l'arborescence avec les groupes et les mots.

Alors arborescence sur les mots et/ou sur les groupes ? Telle est la question.
  
les 2 mon capitaine !
je dirais meme les 3 puisqu'il y a aussi mots/groupe de mot
avec en plus un quatrieme outil qui serait le type de groupe de mots (technique/sémentique/parametrageXXX...), je pense que ca sera assez souple et fonctionnel...
:slight_smile:

groupe = définission des propriétés
mots = taxonomie, qualification du contenu.
  

oui, ca c'est important : on n'affecte pas un groupe à un article, une breve ou une rubrique (pas pour "qualifier").
par contre dire que dans telle rubrique on peut utiliser tel groupe de mot, ca, ca serait utile...

BoOz, demain j'essaie joomla :stuck_out_tongue:
  
au troll !!!
:slight_smile:

@++

9

Yoann NOGUES a écrit :

BoOz a écrit :
  

Yoann NOGUES a écrit :

on pourrait avoir donc l'arborescence avec les groupes et les mots.

Alors arborescence sur les mots et/ou sur les groupes ? Telle est la question.
    

Le fonctionnement actuel : arborescence de groupes de mots , et chaque groupe contient des mots
Je suis partisan pour ce principe d'arborescence des mots.

toute fois l'arborescence des groupes me parait intéressante (mais pas indispensable) , pour pouvoir conserver des propriétés différentes (grace aux groupes) sur tous les niveaux de l'arborescence...

vu que l'arborescence sur les groupes est déjà faites , je propose de la laissé.
et je me propose de rajouter l'arborescence sur les mots directement.

dans la structuration des données :
sur les groupes :
id_groupe : comme avant
id_parent : id du groupe parent

sur les mots:
id_groupe: id du groupe parent ( directement ) ou id du secteur de l'arborescence
id_parent : id du mot parent
(id_secteur) : ben ca dépend si on distingue le id_groupe du id_secteur et si oui , on met 0 dans id_groupe quand on id_secteur ? mais bon ca complque un peu les choses ...

et vous ?
  

ah non malheureux, il faut pas recoder comme les rubriques de spip, mais bien avec une gestion intervallaire de l'arborescence. C'est tellement plus efficace dans les boucles ensuite.
Cedric

10

cedric.morin@yterium.com a écrit :

Yoann NOGUES a écrit :

BoOz a écrit :

Yoann NOGUES a écrit :

on pourrait avoir donc l'arborescence avec les groupes et les mots.

Alors arborescence sur les mots et/ou sur les groupes ? Telle est la question.
    

Le fonctionnement actuel : arborescence de groupes de mots , et chaque groupe contient des mots
Je suis partisan pour ce principe d'arborescence des mots.

toute fois l'arborescence des groupes me parait intéressante (mais pas indispensable) , pour pouvoir conserver des propriétés différentes (grace aux groupes) sur tous les niveaux de l'arborescence...

vu que l'arborescence sur les groupes est déjà faites , je propose de la laissé.
et je me propose de rajouter l'arborescence sur les mots directement.

dans la structuration des données :
sur les groupes :
id_groupe : comme avant
id_parent : id du groupe parent

sur les mots:
id_groupe: id du groupe parent ( directement ) ou id du secteur de l'arborescence
id_parent : id du mot parent
(id_secteur) : ben ca dépend si on distingue le id_groupe du id_secteur et si oui , on met 0 dans id_groupe quand on id_secteur ? mais bon ca complque un peu les choses ...

et vous ?
  

ah non malheureux, il faut pas recoder comme les rubriques de spip, mais bien avec une gestion intervallaire de l'arborescence. C'est tellement plus efficace dans les boucles ensuite.
Cedric

je sais mais n'ayant jamais utilisé l'intervallaire ( bien que ce ne soit pas super compliqué en soit) , je me pose pas mal de questions quand a la déclaration des critéres des boucles ... ( et déjà que j'ai du mal a rentrer dans le core ... si j'ai pas d'exemples je vais mettre des jours et des jours a faire tout ca ... )

pour changer un poil de sujet, pour modifier le code qui est dans légender j'ai cherché un pipeline qui permettrait d'ajouter l'attribution des mots clefs... mais yen a pas ...( bon ya bien affiche_gauche

est-ce que dans la svn, ya un projet d'intégrer des pipelines un peu partout ?
ca serait plutot bien pour éviter les surcharges, non ?

Merci

11

Stephane a écrit :

RealET a écrit :

* Fil tapuscrivait, le 14/09/2007 10:23:
  

serait-il interessant ( ma réponse est oui) que l'on regroupe les
plugins mots techniques et mots partout arbo ?
        

à priori non, car mots techniques a vocation à entrer dans le core,
alors que les mots arborescents probablement pas
    

Par contre, que les mots arborescent puissent s'adjoindre aux mots technique sans surcharge du core (donc avec les bons points d'entrées), ça serait très souhaitable.

oui clairement.
mais il faudrait alors que mots_techniques reprenne la gestion "generique" des mots clés de mots_partout et mette les points d'entrée ou il faut.
mots_partout serait alors une simple extension des mots clés.

Mais le probleme, encore une fois, c'est les interfaces d'administration.
Pour l'instant, l'onglet dans la config qui s'appuie sur un gros tableau de parametrage (mélangeant beaucoup de choses...), c'est bof...

sinon, pour l'arborescence de mots, c'est quoi l'idée ?
un id_parent au niveau du mot ?

@++

Fil a raison sur le fait que le patch concernant les mots clés techniques (proposé sous forme de plugin juste pour tester) a vocation à rentrer dans le core. Par contre, que les mots clés techniques soient intégrés ou non au core, ca ne règle pas la question des points d'entrée génériques du core pour permettre aux plugins de s'y brancher. C'est là où il faut réfléchir aux bons points d'entrées (partir de l'expérience de mots partout) à intégrer au core. Une fois ces points d'entrées intégrés, un plugin permettant de gérer les extensions des mots-clés et de gérer des mots clés arborescents (d'une manière ou d'une autre) sera un vrai plus (mais il faut pouvoir paramétrer le plugin pour activer que les fonctionnalités dont on a besoin). Par ailleurs, cela devrait permettre à agenda d'étendre les mots clés aux évènements sans souci et sans que mots_partout ne s'en charge par ailleurs car avec des points d'entrée génériques plusieurs plugins devraient pouvoir agir sans se conterdire mutuellement (on a bien ce fonctionnement aujourd'hui avec les tables non natives, plusieurs plugins peuvent déclarer de nouvelles tables sans problème).
reste qu'outre les points d'entrée génériques, il faudra que les fonctions de gestion des mots clés du core soient plus génériques : dénombrement des objets associés à un mot clés, suppression d'un mot-clé (et donc supression du lien avec les objets joints), case à cocher des groupes de mots clés concernant la possibilité d'associer un mot à chaque type d'objet, et tout le problème des chaines de langue pour ces différentes interfaces (je renvoie aux discussions ici sur ce sujet il y a 6 mois)

12

* cedric.morin@yterium.com tapuscrivait, le 14/09/2007 11:55:

ah non malheureux, il faut pas recoder comme les rubriques de spip, mais bien avec une gestion intervallaire de l'arborescence.

Y'a 2 mois environ sur spip dev, quand j'ai lancé un thread sur le sujet pour les rubriques, il y a eu une objection sur les transactions dans MySQL qui rendaient impossible une mise à jour sûre d'un arbre.
Et tu avais dit que F&T avait la gestion intervallaire.
Tu as résolu le problème de l'intégrité comment ?

--
RealET

13

RealET a écrit :

* cedric.morin@yterium.com tapuscrivait, le 14/09/2007 11:55:

ah non malheureux, il faut pas recoder comme les rubriques de spip, mais bien avec une gestion intervallaire de l'arborescence.
    

Y'a 2 mois environ sur spip dev, quand j'ai lancé un thread sur le sujet pour les rubriques, il y a eu une objection sur les transactions dans MySQL qui rendaient impossible une mise à jour sûre d'un arbre.
Et tu avais dit que F&T avait la gestion intervallaire.
Tu as résolu le problème de l'intégrité comment ?

Je n'ai pas implémenté cet aspect des choses mais j'y ai reflechi :
Le premier point à prendre en compte est le probleme des acces conccurent.
Il y a 3 fonctions de manipulation des arbres :
arbre_inserer_element()
arbre_supprimer_element()
arbre_deplacer_element()

Toutes les manipulations d'organisation de l'arbre doivent passer par ces fonctions, on peut donc y gérer un verrou pour eviter tout probleme de manipulations concurrentes.

Le second point à gérer est le cas de perte de connexion en cours de manipulation, c'est a dire au milieu des 2 (ou 3 dans le cas de creation d'un parent, que l'on utilise pas dans spip actuellement) requettes necessaires à la modification.
Sur ce point, j'ai optimisé l'écriture des requettes afin d'assurer un maximum de coherence.
Mais on ne peut pas exclure qu'une requete soit partiellement executee, et dans ce cas on peut avoir des chevauchements, qui sont alors inextricables.

Pour ne prendre aucun risque, la meilleure solution est sans doute de gerer les deux mecanismes :
- id_parent sur chaque noeud qui donne la hierarchie de reference car toutes les operations y afférent sont atomiques et sures (mais il n'y a pas de notion d'ordre des enfants)
- gestion intervallaire en doublon qui permet des operations de selection beaucoup plus rapides dans les boucles sur tout ce qui est branche, enfants, parents, hierarchie etc ...
On a au final quelque chose de plus lourd dans le code de mise a jour, mais il peut etre centralisé, cela reste malgré tout plus léger comme operation de la mise a jour que le 'propager_les_secteurs' que l'on a actuellement.
En cas de probleme d'integrité, on reconstruit les intervalles à partir des pointeurs id_parent.

Il faut se donner la peine d'ecrire proprement l'api de façon générique qui pourra ensuite etre utilisée pour n'importe quelle table.

Cedric