Un rang sur les tables de jointures pour les objets de type mot ou document me parait plus pertinent que le fonction actuel pour ces objets. Éventuellement, que l’on conserve l’ancien comportement (le rang dans le titre de l’objet) si le rang sur la table de jointure n’est pas renseigné pour l’objet lié.
Qu’en pensez vous ? S’il n’est pas prévu ce genre d’évolution, dois-je y travailler dans le plugin rang ? un nouveau ?
Oui le chantier est dans ce plugin pour le moment.
L’idée est de défricher le problème dans un plugin, et d’intégrer quand ça sera mûr. Dans ce process, il arrive aussi qu’on lève des points de blocage dans le core,
auquel cas on essaye de faire évoluer.
C’est un beau chantier car sur les objets principaux, le rang doit porter sur l’objet lui meme, et sur les objets attachés, sur la liaison.
Ensuite il faut gérer l’interface dans tous les cas
Donc ne te prive pas d’y aller
Je pense que tu peux casser le plugin rang pour en faire ce qui te paraît le mieux.
C’est un beau chantier car sur les objets principaux, le rang doit porter sur l’objet lui meme, et sur les objets attachés, sur la liaison.
Que reste-t-il comme « objets principaux » ? Tout est rattach(é|able) à quelque chose d’autre, non ?
Sauf les groupes de mots, peut-être… encore que les rattacher à une rubrique (dont la racine) pour qu’ils ne s’appliquent qu’à la branche correspondante, serait intéressant…
C’est un beau chantier car sur les objets principaux, le rang doit porter sur l’objet lui meme, et sur les objets attachés, sur la liaison.
Que reste-t-il comme « objets principaux » ? Tout est rattach(é|able) à quelque chose d’autre, non ?
Sauf les groupes de mots, peut-être… encore que les rattacher à une rubrique (dont la racine) pour qu’ils ne s’appliquent qu’à la branche correspondante, serait intéressant…
-Nicolas
objets principaux → qui n’ont pas une table objets_liens, et donc pour classer, y a pas 36000 solutions
objets attachés → ceux qui en ont une, et donc pour classer, y a soit mettre le rang sur l’objet et des rangs spécifiques sur le liens qui prendront le dessus si on se trouve sur l’objet lié, soit mettre le rang sur le lien tout court.
exemple concret :
Je classe les articles → je les numérote tout court
Je classe les mots → je les numérote tout court
Je classe les mot d’un article (mais je veux pas changer le classement des mots) → je numérote la liaison entre mots et articles donc la table mots_liens
Donc soit j’ai pas compris ce que tu voulais dire, soit c’est hs pour le rang, soit il me manque une subtilité.
C’est un beau chantier car sur les objets principaux, le rang doit porter sur l’objet lui meme, et sur les objets attachés, sur la liaison.
Que reste-t-il comme « objets principaux » ? Tout est rattach(é|able) à quelque chose d’autre, non ?
Sauf les groupes de mots, peut-être… encore que les rattacher à une rubrique (dont la racine) pour qu’ils ne s’appliquent qu’à la branche correspondante, serait intéressant…
objets principaux → qui n’ont pas une table objets_liens, et donc pour classer, y a pas 36000 solutions
objets attachés → ceux qui en ont une, et donc pour classer, y a soit mettre le rang sur l’objet et des rangs spécifiques sur le liens qui prendront le dessus si on se trouve sur l’objet lié, soit mettre le rang sur le lien tout court.
exemple concret :
Je classe les articles → je les numérote tout court
Les articles sont rattachés à une (core) ou plusieurs (polyhiérarchie) rubrique(s)…
Je classe les mots → je les numérote tout court
Tu classes implicitement le « lien » entre le mot et son groupe.
Je classe les mot d’un article (mais je veux pas changer le classement des mots) → je numérote la liaison entre mots et articles donc la table mots_liens
Donc soit j’ai pas compris ce que tu voulais dire, soit c’est hs pour le rang, soit il me manque une subtilité.
Disons que je vois peut-être à plus long terme, avec des liens possibles dans tous les sens de toute façon…
On peut aller jusqu’à vouloir classer d’une manière les articles liés à un mot, et d’une autre manière les mots liées à un article…
Ca ne change rien, c’est aussi un rang sur la table de liens. Mais effectivement, faut gérer rang_objet et rang_lien pour ces tables. En rang deux par deux quoi.
Non, non, c’est toujours rang_lien, c’est juste qu’il faut deux enregistrements…
Euh là c'est pas logique du tout. Les liens dans SPIP n'ont jamais été directionnels. C'est dans les deux sens. Donc il n'y a qu'un seul enregistrement par lien. Qu'après il y ait besoin de deux classements n'implique pas deux liens différents.
Sauf si on ajoute une *qualification* du lien. On en avait parlé un jour, je crois. Pour les documents notamment.
Non, non, c’est toujours rang_lien, c’est juste qu’il faut deux
enregistrements…
Euh là c’est pas logique du tout. Les liens dans SPIP n’ont jamais été directionnels.
Bin une rubrique est à l’intérieur d’une autre, et l’inverse n’est pas vrai, c’est directionnel
C’est dans les deux sens. Donc il n’y a qu’un seul enregistrement par lien. Qu’après il y ait besoin de deux classements n’implique pas deux liens différents.
Ce serait pourtant plus simple de toujours trier sur le même champ, quel que soit le sens du lien qu’on veut montrer…
Sauf si on ajoute une qualification du lien. On en avait parlé un jour, je crois. Pour les documents notamment.
M’enfin, on en est pas encore là hein.
Certes, mais autant ne pas se mettre tout de suite des battons dans les futures roues…
Non, non, c'est toujours rang_lien, c'est juste qu'il faut deux
enregistrements...
Euh là c'est pas logique du tout. Les liens dans SPIP n'ont jamais
été directionnels.
Bin une rubrique est à l'intérieur d'une autre, et l'inverse n'est pas
vrai, c'est directionnel
sauf que une rubrique n'est (normalement) à l'intérieur que d'une seule rubrique. Alors qu'un mot clef peut-être lié à plusieurs articles et un article peut avoir plusieurs mot clefs. C'est d'ailleur pour cela que la rubrique parente d'une rubrique n'est pas stockée dans une table à part.
