Re: r23368 - spip/ecrire/public

Le 01/02/2017 à 13:33, nicod_ a écrit :
> Je me glisse dans la conversation pour indiquer qu'il y a un plugin Rang
> sur la zone, qui ajoute un rang aux objets choisis, avec une interface
> de tri par drag/drop.
>
> https://zone.spip.org/trac/spip-zone/browser/_plugins_/rang/trunk

Tu fais bien de montrer ce plugin car il m'avait échappé.
J'ai du coup regardé un peu. Et cela me pose encore d'autres questions :)

1) Le plugin fait le choix (actuellement) de proposer d'installer "rang" 
sur les tables qui ont un champ "id_rubrique" uniquement. Du coup il 
n'est pas possible d'ordonner les mots d'un groupe de mots pour 
l'instant avec.

Si l'on part du principe qu'il faut un "parent" connu pour pouvoir gérer 
les listes avec des rangs créés par glisser-déposer, alors il faut avoir 
connaissance de la parenté pour l'objet éditorial concerné, et donc, 
cela rejoint le ticket https://core.spip.net/issues/3844 et ceux qui 
gravitent autour.


1b) Certaines listes d'objets éditoriaux se suffisent à elles-mêmes sans 
parents, notamment pour les objets éditoriaux créés pour des plugins. 
Comment distinguer ces cas dans les listes ?

Algorithme possible :?
- si j'ai un champ 'rang' déclaré
- si j'ai l'option rang cochée en configuration pour cet objet (?)
- j'ai un parent déclaré ?
   [oui] --> l'environnement de la liste a ce parent ?
   -> [Oui] -> afficher la colonne rang
   -> [Non] -> pas de rang
   [Non] --> afficher la colonne rang


2) Il est facile d'imaginer pour les articles (ou rubriques) que dans 
certaines rubriques on souhaite des numéros, et pas dans d'autres. La 
liste des articles qui n'ont pas de "rang" encore affecté voit 
actuellement avec le plugin une colonne avec des 0. partout. Faut il 
afficher le zéro si rang vaut zéro (ce qui signifie qu'il n'a pas été 
encore défini) ?

De même on pourrait imaginer dans ce cas que l'ensemble de la colonne 
rang n'est pas affichée, mais cela ferait faire un calcul en plus, soit 
au squelette, soit en JS pour virer la colonne si elle n'a que des zéros 
ou du vide.


3) La colonne de rang est intitulé dans la liste "Nº", et la colonne qui 
a l'identifiant d'article est renommée elle de "Nº" en "Id". La colonne 
de statut porte la marque "#".

Bien que ça ne soit pas très grave, il me semble que le nº d'article 
doive rester avec l'intitulé numéro, que l'on retrouve à divers endroit 
de l'interface. Par contre, la colonne de rang pourrait avantageusement 
recevoir un "#" (c'est l'usage en anglais de ce signe d'ailleurs).

Mais du coup, la colonne Statut avec son "#" aussi serait mal intitulée.


4) Il devient impossible de saisir directement les numéros souhaités 
(hormis peut être si on autorise la saisie de "10. Titre" dans le champ 
titre, qui mettrait automatiquement rang sur la valeur 10). Et dès que 
l'on réordonne les rang sont renumérotés.

C'est un comportement du coup différent de ce que permettait les numéros 
de titres, et cela questionne, surtout pour la migration des squelettes 
des sites, qui pourraient s'attendre tester certaines valeurs, genre "si 
le numéro est 999. alors tu ignores".


C'est déjà une bonne tartine, je m'arrête là pour cette première vague. :)
Des commentaires autour de cela ?

MM.