Re: Ordre et Rang sont dans un bateau...

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 !

-- 
Cédric