Re: r23368 - spip/ecrire/public

Le 31/01/2017 à 20:40, RealET a écrit :

>> 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.

[...]

> 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).

Je vais effectivement peut être le reverter, ou déplacer cette feature 
dans Bonux. Ça améliore {par titre} en mettant bien "100. titre" après 
"20. titre", mais ça ne corrige pas non plus un titre "900000 euros" qui 
passerait inévitablement en premier avec une telle valeur, alors qu'ici 
ce n'est pas un rang.

> 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 :

Plus facile à écrire qu'à faire !

> 1) migration remplissant le champ rang

- On le crée sur quels objets ?
- Comment on le montre / saisie dans l'interface ?
- Est-ce utile pour tous les sites ? Est-ce que ça doit être une option 
pour chaque objet ?
- pour quels champs (uniquement le 'titre' principal) ?
(pour rappel on peut indiquer n'importe quel champ dans {par num xxx})

> 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

C'est compliqué, mais pas irréaliste non plus.

Accessoirement un problème avec {par rang} sera pareil que {par num 
titre} : les éléments sans numéros (avec rang=0) seront affichés en 
premier, ce qui ne sera peut être pas ce qui est souhaité partout.

MM.