[spip-dev] r23368 - spip/ecrire/public

[RealET]

marcimat@rezo.net a écrit le 31/01/2017 à 17:33 :

Author: marcimat@rezo.net
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

[marcimat (Matthieu Marcillaud)]

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.

[maieul (Maïeul Rouquette)]

.

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.

ca on pourrait le résoudre en mettant un rang negatif par défaut non?

[nicod]

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

Il y reste des choses à faire, on en a parlé avec peetdu, mais il y a déjà une base.

[marcimat (Matthieu Marcillaud)]

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.

[JLuc]

Plusieurs discussions ont eu lieu récemment sur des évolutions de spip
(concept de portfolio, modèles docs et {documents}, {collecte}, connection à l'inscription...)
pour lesquelles je n'ai pas vu se dégager de solution ou vision claire
(mais détrompez moi si des perspectives claires se sont dégagées !).

Il me semble que la gestion de l'historique et la compatibilité avec les anciens sites
complexifie énormément la conception d'une bonne solution,
et que ce boulet paralyse l'imagination et l'émergence d'un consensus,
depuis parfois très très longtemps pour certains de ces points.

Alors peut être faut il vraiment envisager un SPIP 4
pour lesquels les devs jusque là bloqués pourront plus facilement se concevoir
en abandonnant la contrainte "compatibilité des anciens squelettes".

JL

[b_b]

Hop,

Il me semble que la gestion de l'historique et la compatibilité avec les
anciens sites
complexifie énormément la conception d'une bonne solution,
et que ce boulet paralyse l'imagination et l'émergence d'un consensus,
depuis parfois très très longtemps pour certains de ces points.

Ce "boulet" comme tu le dis est amha la force de SPIP et c'est pour ça qu'on met très souvent en avant le fait que la compatibilité ascendante entre les différentes versions de SPIP est assurée.

Alors peut être faut il vraiment envisager un SPIP 4
pour lesquels les devs jusque là bloqués pourront plus facilement se
concevoir
en abandonnant la contrainte "compatibilité des anciens squelettes".

Ahma toujours, c'est une mauvais idée que de vouloir simplifier la vie des devs au détriment de celles des utilisateur⋅ice⋅s.

Pour en revenir à la question de la version de la prochaine release. Il semblait se dégager un accord commun pour sortir une 3.2 afin d'être certain de la sortir dans l'année, voir même avant cet été. Et peut-être même lancer une dynamique de release plus fréquentes sur le Y en ajoutant des fonctionnalités au coup par coup (cf les tickets roadmap). Du coup, j'ai peur qu'on se lance dans un chantier sans fin si on part sur l'idée du 4.0 qui casse tout.

[JLuc]

Excuse moi marcimat ma réponse diverge pas mal de ton post initial.

J'ai lu aussi la réponse de b_b et j'espère que toutes réflexions hivernales
porteront des bourgeons au printemps,
et des fleurs et ds fruits plus tard dans l'année...

JLuc

j'ai encore abordé Le 03/02/2017 à 19:41, Bruno Bergot a écrit :

[eric_tonton (Eric Lupinacci)]

Hello,

[marcimat (Matthieu Marcillaud)]

Pour faire court, je suis d'accord avec JLuc, b_b et Eric !

Je suis par exemple frustré de ne pas utiliser dans SPIP des outils externes plus modernes, maintenus par d'autres gens, et qui permettrait de se concentrer justement sur l'expérience qu'on souhaite offrir au final à nos utilisateurs rédacteurs et visiteurs des sites.

Par exemple Composer ou Twig, ou un autoloader pour fonctions PHP plutôt que de devoir mettre plein de include_spip() parfois à juste titre, parfois "aucazou" ; mais aussi utiliser un framework CSS dans l'espace privé plutôt que de difficilement gérer nos affichages parce qu'on n'a aucune grille, à peine une petite charte (ce qui est déjà bien). Ou encore avoir un éditeur Markdown par défaut qui colore les éléments de syntaxe ou je ne sais quoi.

Mais c'est quasiment impossible d'intégrer ces choses en conservant une compatibilité. On se retrouve un peu entre deux mondes. Les gens du PHP-FIG tentent d'améliorer les interconnexions de modules entre les projets, et nous à l'autre bout on est avec nos petites fonctions PHP, JS ou CSS persos qu'on a du mal à maintenir

D'un autre point de vue, pour un site donné, c'est rassurant de savoir que lorsqu'on va passer à la version suivante de SPIP, on aura un minimum de choses à corriger dans les Squelettes et les plugins. Et on est tout autant heureux.

Ce grand écart n'est pas facile.

Des bises et des soleils avant la tempête

MM.

[nicod]

Ce "boulet" comme tu le dis est amha la force de SPIP et c'est pour ça
qu'on met très souvent en avant le fait que la compatibilité ascendante
entre les différentes versions de SPIP est assurée.

+1, c'est ce qui fait que SPIP a encore des utilisateurs fidèles.
Pas si nombreux, en plus, ne les perdons pas.

Ahma toujours, c'est une mauvais idée que de vouloir simplifier la vie
des devs au détriment de celles des utilisateur⋅ice⋅s.

+1 aussi, pour la même raison.

[nicod]

Pour faire court, je suis d'accord avec JLuc, b_b et Eric !

Et moi aussi

D'un autre point de vue, pour un site donné, c'est rassurant de savoir
que lorsqu'on va passer à la version suivante de SPIP, on aura un
minimum de choses à corriger dans les Squelettes et les plugins. Et on
est tout autant heureux.

Ce grand écart n'est pas facile.

Ouais.
Mais il faut une roadmap, comme dit Eric, et pas que.
Se demander ce qu'est SPIP aujourd'hui.

Y'a plein de choses bien dans SPIP, mais que personne ne connait.
Un moteur de template, un lecteur de RSS, de la minification d'assets, plein de trucs qui mériteraient d'être distribués comme des libs ou des packages composer, ou autres...

Je suis d'accord avec marcimat, on a un chouette outil, mais on a du mal à le partager, et ça me rend souvent grognon.