[SPIP Zone] r109779 - in _plugins_/produits/trunk

Archives Zone
1

Le 03/04/2018 à 09:49, spip-zone-commit@rezo.net a
écrit :

Log:
Compatibilité avec le plugin Rang

Hello peetdu
Là c'est pas de la compatibilité, c'est de l'utilisation forcée, sans
pour autant avoir mis Rang en <necessite>.

Là tous les gens qui ont Produits sans avoir Rang ça va planter chez
eux, avec utilisation de fonction qui n'existe pas (et chaine de langue).

Le point le plus important à faire avec Rang c'est qu'il sache s'insérer
tout seul dans n'importe quelle liste d'objet. Tant qu'il ne sait pas
faire ça, il ne sert pas des masses et il reste expérimental. Car ce
n'est pas possible de se baser sur le fait que tous les objets du monde
vont devoir modifier leur propre liste pour être ok avec Rang, ça ne
peut pas marcher comme ça.

Il faut absolument que Rang s'insère avec recuperer_fond dans n'importe
quelle liste normée (prive/objets/liste/<type>.html), pour les objets
qu'on a configuré comme étant triable évidemment, et qu'il ajoute SA
colonne, soit tout au début, soit tout à la fin, dans le <thead><tr> et
dans chaque <tr> du <tbody>. C'est possible en regex à priori.

- pipeline recuperer_fond
- on teste si on est dans un squelette prive/objets/liste/trucs.html
- on teste si "trucs" est un objet configuré pour être triable
- si oui, on ajoute la colonne au début ou à la fin

--
RastaPopoulos

2

Le 03/04/2018 à 13:06, RastaPopoulos a écrit :

C'est possible en regex à priori.

Mais c'est très laid, et pas super robuste.

--
nicod_

3

Le 03/04/2018 à 13:12, nicod_ a écrit :

Mais c'est très laid, et pas super robuste.

Beaucoup moins laid que de demander à chaque objet de modifier ses
squelettes pour que ça marche. :slight_smile:

Ça reste pas le mieux ok, mais on ne va pas nécessiter tout le plugin
Query Path juste pour ça, ça me parait un peu énorme juste pour un petit
ajout.

Surtout que là, on ne cherche pas à ajouter un truc complexe en plein
milieu avec des sélecteurs compliqués. Regex suffit normalement
largement pour juste insérer un élément avant la fin d'une balise : la
fin de chaque </tr> : ça sera toujours toujours ça, donc quand même
robuste et toutes les listes d'objets de l'admin doivent déjà être
normées pareilles.

--
RastaPopoulos

4

Le 03/04/2018 à 13:12, nicod_ a écrit :

Mais c'est très laid, et pas super robuste.

En fait, la modif obligatoire dans une liste d'objets, au niveau fonctionnel, c'est de récupérer l'id_objet de la ligne qu'on déplace.
Ça se traduit pour l'instant par l'ajout d'un id="id_#ID_PRODUIT" sur le <tr>.
Les autres ajouts sont "cosmétiques" (affichage du picto et de la valeur du rang).

--
nicod_

5

Le 03/04/2018 à 13:18, nicod_ a écrit :

Ça se traduit pour l'instant par l'ajout d'un id="id_#ID_PRODUIT" sur le
<tr>.
Les autres ajouts sont "cosmétiques" (affichage du picto et de la valeur
du rang).

Oui pour l'id.

Après sur le long terme, je me dis que le mieux ça serait quand même que
toutes les listes d'objet du monde aient ça (là ça serait une modif
générique, qu'on devrait demander à tous).

Et pour que ça marche même quand il y a plusieurs listes dans la même
page (là id_123, dans une rubrique, il peut y avoir des articles, des
produits, des patates, c'est pas valide), ça devrait pas être dans
l'attribut id="". Ça devrait être dans data-id ou dans data-id_objet ou
dans data-id_<type> donc là data-id_produit.

Quand à la colonne ajoutée, m'est-avis que ce n'est pas que de la
cosmétique. En effet, obliger à avoir javascript + dans tous les cas
obliger à ne déplacer que en drag-n-drop, ce n'est pas très pratiques
pour celleux qui n'ont pas la dextérité adéquat.

Donc une idée serait que quand c'est une liste d'un objet configuré
triable, ça ajoute bien une colonne entière, au début ou à la fin,
contenant :
- un picto "attrapable" pour drag-n-drop pour les gens qui peuvent
- un bouton action "monter"
- un bouton action "descendre"

Et donc ce serait accessible, fonctionnerait aussi sans JS, aussi au
clavier, pour les gens qui peuvent pas drag-n-drop.

--
RastaPopoulos

6

Gros zap, c'est corrigé avec z109782. Merciiii !

Après sur le long terme, je me dis que le mieux ça serait quand même que
toutes les listes d'objet du monde aient ça (là ça serait une modif
générique, qu'on devrait demander à tous).

Je pense que en lisant ça :
https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/balises.php#L934

…on est tous d'accord là-dessus.

Et pour que ça marche même quand il y a plusieurs listes dans la même
page (là id_123, dans une rubrique, il peut y avoir des articles, des
produits, des patates, c'est pas valide), ça devrait pas être dans
l'attribut id="". Ça devrait être dans data-id ou dans data-id_objet ou
dans data-id_<type> donc là data-id_produit.

Ok pour l'utilisation de HTML5 data attributes. Tcharlss en parlait sur IRC l'autre jour.

Il y a t-il une contre-indication à juste utiliser data-id ?

Dans la suite de cette idée, il faudrait aussi un data-objet ou data-objet-lie dans le [table / div / ul] englobant, le scripte ayant besoin de connaitre la nature de l'objet a trier.

Quand à la colonne ajoutée, m'est-avis que ce n'est pas que de la
cosmétique. En effet, obliger à avoir javascript + dans tous les cas
obliger à ne déplacer que en drag-n-drop, ce n'est pas très pratiques
pour celleux qui n'ont pas la dextérité adéquat.

Donc une idée serait que quand c'est une liste d'un objet configuré
triable, ça ajoute bien une colonne entière, au début ou à la fin,
contenant :
- un picto "attrapable" pour drag-n-drop pour les gens qui peuvent
- un bouton action "monter"
- un bouton action "descendre"

Et donc ce serait accessible, fonctionnerait aussi sans JS, aussi au
clavier, pour les gens qui peuvent pas drag-n-drop.

Archi d'accord.

Existe-il déjà des plugins sur la zone qui proposent le "monter / descendre" au clavier ?

Peedtu

7

Le 03/04/2018 à 15:49, Peetdu a écrit :

Il y a t-il une contre-indication à juste utiliser data-id ?

Oui, "id" c'est super vague, et il vaut mieux que ce soit propre à ce
qu'on va mettre dedans.

Par exemple saisies utilise aussi des "id" tout court mais pour y mettre
des identifiants uniques générés aléatoirement (genre @ae34fmachinchose).

Là on sait pertinemment qu'on parle d'identifiant SQL d'objets
éditoriaux de SPIP. Donc il faut que ce soit "id_objet" ou "id_patate".

Dans la suite de cette idée, il faudrait aussi un data-objet ou
data-objet-lie dans le [table / div / ul] englobant, le scripte ayant
besoin de connaitre la nature de l'objet a trier.

Tout à fait, Charles m'a dit pareil tout à l'heure. Autant ne le mettre
qu'une seule fois.

Pour ces deux points, avec Charles on s'est dit un truc qui peut être
élégant tout à l'heure :
- le plugin s'insère dans recuperer_fond
- teste si on est dans un /prive/objets/liste/trucs.html
- SI l'objet a déjà ajouté des data-id_objet="", on ne les ajoute pas
- SINON on cherche la colonne "id" de la <table>, et toujours en PHP, on
rajoute le data-id_objet sur chaque ligne, avec la valeur de cette colonne

Le but est qu'à la fin, que ce soit un objet déjà raccord avec Rang *ou
pas*, on est toujours un data-id_objet sur chaque ligne.

Ce n'est pas au javascript ou à d'autres PHP qui viennent plus tard, de
refaire ces tests de l'un ou l'autre. Après ce passage, on a toujours la
bonne info de la même manière.

Par ailleurs, après avoir fait ça, Rang toujours, doit quand même
ajouter une colonne (au début ou à la fin) avec les boutons et le picto
attrapable.

Et donc ce serait accessible, fonctionnerait aussi sans JS, aussi au
clavier, pour les gens qui peuvent pas drag-n-drop.

Archi d'accord.

Existe-il déjà des plugins sur la zone qui proposent le "monter /
descendre" au clavier ?

Oui, le plugin Sélections éditoriales et le plugin Menus, ont des
boutons d'action pour monter et descendre les lignes, et donc changer
les rangs.

Et d'ailleurs pour Sélections éditoriales, c'est bien avec un champ
"rang" dans la table des spip_selections_contenus. Donc ça colle
parfaitement à cette utilisation (le parent étant la spip_selections).

--
RastaPopoulos

8

Bon, c'est cool, ça avance bien cette affaire :slight_smile:

Le 03/04/2018 à 17:39, RastaPopoulos a écrit :

Le 03/04/2018 à 15:49, Peetdu a écrit :

Il y a t-il une contre-indication à juste utiliser data-id ?

Oui, "id" c'est super vague, et il vaut mieux que ce soit propre à ce
qu'on va mettre dedans.
Là on sait pertinemment qu'on parle d'identifiant SQL d'objets
éditoriaux de SPIP. Donc il faut que ce soit "id_objet" ou "id_patate".

Bon on y va pour un data-id_objet='18' ? (voir ci-dessous quand même)

Dans la suite de cette idée, il faudrait aussi un data-objet ou
data-objet-lie dans le [table / div / ul] englobant, le scripte ayant
besoin de connaitre la nature de l'objet a trier.

Tout à fait, Charles m'a dit pareil tout à l'heure. Autant ne le mettre
qu'une seule fois.

Pour ces deux points, avec Charles on s'est dit un truc qui peut être
élégant tout à l'heure :
- le plugin s'insère dans recuperer_fond
- teste si on est dans un /prive/objets/liste/trucs.html
- SI l'objet a déjà ajouté des data-id_objet="", on ne les ajoute pas
- SINON on cherche la colonne "id" de la <table>, et toujours en PHP, on
rajoute le data-id_objet sur chaque ligne, avec la valeur de cette colonne

Le but est qu'à la fin, que ce soit un objet déjà raccord avec Rang *ou
pas*, on est toujours un data-id_objet sur chaque ligne.

Ce n'est pas au javascript ou à d'autres PHP qui viennent plus tard, de
refaire ces tests de l'un ou l'autre. Après ce passage, on a toujours la
bonne info de la même manière.

Oupss, j'ai l'impression que tu reviens sur ce que tu disais tout à l'heure ("Oui pour l'id. Après sur le long terme, je me dis que le mieux ça serait quand même que toutes les listes d'objet du monde aient ça")

Et puis il est un cas où cela ne marche pas : l'ordonnancement des rubriques elles-mêmes : il n'y a pas de colonne "id".
Et sans peut être encore d'autres cas ?

Je pense que les items à trier viennent toujours avec une structure du genre

div data-objet='patates'
  div data-id_objet='2'
  div data-id_objet='4'
  div data-id_objet='5'

ou

div data-objet_liaison='auteurs'
  div data-id_liaison='2'
  div data-id_liaison='4'
  div data-id_liaison='5'

... et effectivement ajouter à la volée les pictos [attrapable | monter | descendre]

Existe-il déjà des plugins sur la zone qui proposent le "monter /
descendre" au clavier ?

Oui, le plugin Sélections éditoriales et le plugin Menus, ont des
boutons d'action pour monter et descendre les lignes, et donc changer
les rangs.

Comment ça marche avec le clavier ?

Drop&Peetdu

9

Le 03/04/2018 à 18:38, Peetdu a écrit :

Bon on y va pour un data-id_objet='18' ? (voir ci-dessous quand même)

Oupss, j'ai l'impression que tu reviens sur ce que tu disais tout à
l'heure ("Oui pour l'id. Après sur le long terme, je me dis que le mieux
ça serait quand même que toutes les listes d'objet du monde aient ça")

Non ce n'est pas un retour sur l'idée, c'est justement là où est la
solution "élégante" discuté avec Charles tout à l'heure :
- si un objet implémente déjà la bonne information dès l'origine : c'est
super ! on ne fait rien !
- si c'est un ancien objet, du core ou d'un autre plugin, qui
n'implémente pas encore cette information : on est intelligent, élégant,
on a un fallback, et *si on peut*, donc si on trouve une colonne d'id,
et bien on arrive quand même à trouver l'information et on ré-insère un
data-id_objet sur chaque ligne (dès le PHP, pour que ce soit dispo pour
tous ensuite).

Et puis il est un cas où cela ne marche pas : l'ordonnancement des
rubriques elles-mêmes : il n'y a pas de colonne "id".
Et sans peut être encore d'autres cas ?

Oui, je ne dis pas qu'il n'y a pas quelque cas où on n'arrive pas à
trouver l'information dans le fallback. Mais ça n'empêche pas d'avoir le
fallback quand même pour tous les objets (99,9%) où ça va permettre de
les rendre compatible d'office même sans les avoir modifié. C'est ça qui
est magique.

Pour les quelques cas où le fallback ne trouve pas l'info (je ne vois
que les rubriques pour l'instant), et bien là, il faut faire du cas par
cas et par exemple obligé soit de surcharger la liste dans Rang, soit de
modifier le core, ou autre solution…

Mais c'est un truc rare, le cas le plus courant doit être géré
automatiquement.

Comment ça marche avec le clavier ?

Bah ce sont des boutons Monter et Descendre, des formulaires quoi, avec
des labels dedans qui dit ce que ça fait. Donc c'est accessible, que ce
soit pour les lecteurs d'écran, pour les gens qui naviguent au clavier, etc.

--
RastaPopoulos

10

Le 03/04/2018 à 18:38, Peetdu a écrit :

... et effectivement ajouter à la volée les pictos [attrapable | monter | descendre]

La colonne avec le picto "attrapable" peut être directement insérée en JS, ça sera beaucoup plus propre qu'en regex PHP (et pas de JS, pas de drag, donc ça reste cohérent).

Pour les boutons monter et descendre affichés systématiquement, je ne suis pas fan de l'idée, ça va alourdir l'interface.

--
nicod_

11

Le 04/04/2018 à 14:10, nicod_ a écrit :

Pour les boutons monter et descendre affichés systématiquement, je ne
suis pas fan de l'idée, ça va alourdir l'interface.

Beaucoup moins important qu'avoir des boutons accessibles à tou⋅tes. Y
compris quand il y a JS. Au clavier ou autre moyen. Pour tous les gens
qui ne peuvent pas drag-n-drop, càd : beaucoup.

La fonctionnalité c'est "pouvoir ranger manuellement des choses". Le
drag-n-drop lui c'est de l'amélioration progressive en JS, la cerise en
plus, mais ça ne doit pas être the moyen obligatoire pour le faire.

--
RastaPopoulos