[spip-dev] Ordre et Rang sont dans un bateau...

Dev
1

Hello,

Matthieu Marcillaud a écrit :

C'était justement pour cela que je n'avais pas utilisé "rang" car
j'avais peur d'un effet de bort (j'imaginais que "rang" était plutôt sur
la table de l'objet éditorial, plutôt que sur une table de liens).

En regardant le code, je pense que tant qu'un champ "rang" n'est pas
créé sur spip_documents directement, ça marcherait de mettre "rang" sur
la table de liens. Mais est-ce que rang n'est pas fait pour aller
directement un jour sur l'objet éditorial ? (plutôt que de mettre des
numéros devant les titres ?).

en effet il faut faire là attention à ce que le schema qu'on retient soit générique et généralisable.
Pour les documents on peut en effet se dire que le rang n'a pas de sens pour les documents en eux-même mais uniquement par rapport à chacun de leur lien. Et on pourrait être tenté de mette la balise range sur la table de lien.

Mais on va alors se heurter à un problème avec les mots clés par exemple pour lequel le rang est plus généralement utilisé pour classer les mots-clés dans un groupe. Cela veut dire que si on veut utiliser un ordre par lien, on sera obligé de le nommer autrement et ça sera tout incohérent avec les documents.

3 approches possibles donc :

1/ pour chaque type d'objet on implémente rang sur la table (principale ou liens) qui nous parait le plus pertinente et correspondre à l'usage général.
  + On a un truc qui globalement introduira peu de régression à la migration et fonctionnera "comme avant" ou presque pour les squelettes.
  - on est coincé sur le nommage de l'autre cas (lien ou principal selon les cas)
  - on a un truc bancal

2/ on implémente 'rang' sur la table de l'objet et rang_lien sur la table des liens quand il y en a une.
  + c'est cohérent, généralisable
  + ça va casser les squelettes lors de la migration, typiquement sur les documents

3/ on implémente un autre nom en base : ordre et ordre_lien par exemple, et on modifie le compilateur pour qu'il compile 'rang' selon l'usage généralement admins (donc sur ordre la plupart des cas et sur ordre_lien les cas où il faut)
   + c'est cohérent et généralisable
   + on casse pas (ou quasiment pas) les squelettes existants
   - on ajoute une nouvelle terminologie et de la confusion possible entre rang, ordre et ordre_lien

A vous les studios

2

Salut

Si on peut limiter la compléxité je pense que ce serait mieux donc la
3/ serait à éviter de ce fait.

Comme c'est une évolution majeure, cela ne semble pas choquant d'avoir
un peu de casse sur 2/. Bien sur faut documenter, expliquer, ....
Le 1/ ne répond pas aux différents problèmes.

Km

3

[...]

3 approches possibles donc :

1/ pour chaque type d'objet on implémente rang sur la table (principale
ou liens) qui nous parait le plus pertinente et correspondre à l'usage
général.
+ On a un truc qui globalement introduira peu de régression à la
migration et fonctionnera "comme avant" ou presque pour les squelettes.
- on est coincé sur le nommage de l'autre cas (lien ou principal selon
les cas)
- on a un truc bancal

A priori on oubli.
J'aime bien l'idée d'avoir 2 noms tel que :
- rang et rang_lien ou
- ordre et ordre_lien
Même si pour l'utilisateur d'un squelette ce ne sera peut être pas toujours clair la différence.

2/ on implémente 'rang' sur la table de l'objet et rang_lien sur la
table des liens quand il y en a une.
+ c'est cohérent, généralisable
+ ça va casser les squelettes lors de la migration, typiquement sur les
documents

Alors, à partir de là je décroche. En quoi ça casserait les documents d'avoir un «rang lien» en plus.
Admettons que la boucle actuelle soit «(DOCUMENTS){par num titre, titre}» ou «(DOCUMENTS){par rang, titre}» (s'il y avait un hypothétique champ rang sur spip_documents).

Si on ajoute la colonne "rang_lien" sur spip_documents_liens, valant par défaut 0 tant qu'on n'a pas modifié le tri, changer le squelette en «(DOCUMENTS){par rang_lien, num titre, titre}» ou «(DOCUMENTS){par rang_lien, rang, titre}» ne change pas l'ordre initial de la boucle.

Il faut par contre modifier la boucle dans les squelettes pour que le nouveau rang_lien soit pris en compte (mais de toutes façons {par rang} ne fonctionne pas actuellement non plus car rang n'est pas un champ qui existe.

3/ on implémente un autre nom en base : ordre et ordre_lien par exemple,
et on modifie le compilateur pour qu'il compile 'rang' selon l'usage
généralement admins (donc sur ordre la plupart des cas et sur ordre_lien
les cas où il faut)
  + c'est cohérent et généralisable
  + on casse pas (ou quasiment pas) les squelettes existants
  - on ajoute une nouvelle terminologie et de la confusion possible
entre rang, ordre et ordre_lien

Ça me semble compliqué de faire comprendre que {par rang} fait appel à un champ particulier, pour pas grand chose au final. Il me semblerait plus clair de dire que rang c'est sur les tables principales, et rang_lien sur tables de liens, non ?

D'autres avis ?

4

Matthieu Marcillaud a écrit :

2/ on implémente 'rang' sur la table de l'objet et rang_lien sur la
table des liens quand il y en a une.
+ c'est cohérent, généralisable
+ ça va casser les squelettes lors de la migration, typiquement sur les
documents

Alors, à partir de là je décroche. En quoi ça casserait les documents
d'avoir un «rang lien» en plus.
Admettons que la boucle actuelle soit «(DOCUMENTS){par num titre,
titre}» ou «(DOCUMENTS){par rang, titre}» (s'il y avait un hypothétique
champ rang sur spip_documents).

Si on ajoute la colonne "rang_lien" sur spip_documents_liens, valant par
défaut 0 tant qu'on n'a pas modifié le tri, changer le squelette en
«(DOCUMENTS){par rang_lien, num titre, titre}» ou «(DOCUMENTS){par
rang_lien, rang, titre}» ne change pas l'ordre initial de la boucle.

Il faut par contre modifier la boucle dans les squelettes pour que le
nouveau rang_lien soit pris en compte (mais de toutes façons {par rang}
ne fonctionne pas actuellement non plus car rang n'est pas un champ qui
existe.

Oui tu as raison, de toute façon à partir du moment ou on implémente rang, les {par num titre} des squelettes existants ne trieront plus rien, et il faudra les modifier pour avoir le {par rang} (sauf à ce qu'on modifie le compilateur pour interpréter intelligemment).

Et le fait est que le rang etant alors fonctionnel on aura le même résultat qu'avant, donc rien n'est cassé.
C'est pour profiter du rang sur lien qu'il faudra modifier le squelettes.

Donc en effet ça semble le plus malin de faire ça sur ce scenario.
Et du coup si on se lance sur ce chantier il faut aussi s'occuper de gerer les rang pour tous les objets, ce qui fera un bel upgrade pour la 3.2 !