Re: r23368 - spip/ecrire/public

[email protected] a écrit le 31/01/2017 à 17:33 :
> Author: [email protected]
> Date: 2017-01-31 17:33:40 +0100 (mar, 31 jan 2017)
> New Revision: 23368
>
> Log:
> Du coup, on se permet d'étendre le critère `{par}` avec une nouvelle expression 'sinum' (`{par sinum titre}`), qui va mettre les champs ayant un numéro en premier, et ceux sans numéros après.
> Ainsi le tri `(ARTICLES){par sinum titre, num titre, titre}` va trier : d'abord les articles avec numéros, puis les numéros croissants, puis les titres croissants.
> Pour rappel, l'écriture seule `(ARTICLES){par num titre, titre}` va trier : d'abord les articles sans numéros (ils ont le numéro 0), puis les articles avec numéros
> croissants, puis les titres croissants.
>
> Cette expression ne s'occupe pas de la valeur des numéros. si le champ a un numéro différent de 0, le SELECT 'sinum' vaut 1, sinon (numéro 0 ou pas de numéro)
> sinum vaut 1, ce qui fait que le tri {par sinum} croissant met les 0 ou sans numéros en dernier..
Merci Marcimat pour ça !
C'est fantastique !
Mais en même temps, ça me pose question : ça fait un bout de temps qu'on 
dit que cette méthode du num titre est bancale, et qu'il faudrait 
reporter le classement dans un champ rang (qui existe virtuellement en 
balise #RANG).
Donc, oui, ce que tu viens de coder est une solution.
Mais j'ai l'impression que ça cache la poussière sous le tapis (pour 
reprendre une expression chère à un autre core dev).

Donc, ne serrait-il pas plus productif et générateur de moins de dette 
technique (j'avais tellement envie de sortir ce mot) de se concentrer 
plutôt sur un champ rang :
1) migration remplissant le champ rang
2) post_edition remplissant le champ rang si d'aventure quelqu'un tape 
un num. titre
3) critère {par num titre} se basant prioritairement sur ce champ rang 
de manière transparente pour les squelettes

;-)

-- 
RealET