1) Je viens de déposer un plugin nommé «Ordoc» sur la zone (pas encore zippé mais cela viendra) qui permet (en JS uniquement pour l'instant) de trier les documents liés à un objet éditorial (donc les illustrations, portfolio ou documents) avec une petite icône pour cela.
Techniquement cela ajoute un champ "ordre" sur la table spip_documents_liens et le JS envoie l'ordre des documents d'un bloc (illustrations, portfolio ou documents) lorsqu'on déplace un élément à une action SPIP qui enregistre l'ordre reçu (pour peu qu'il ait changé).
J'aimerais bien un petit retour dessus. D'autre part, je me disais que ça serait bien de l'intégrer directement au plugin Medias de SPIP 3.2-dev (le plugin actuellement est assez petit au bout du compte). Qu'en pensez vous ?
2) Autre demande qui arrive parfois c'est que dès lors qu'il y a plus de, disons, 10 documents sur un article, la liste assez très longue, et ce n'est pas toujours parfaitement pratique. Est-ce que d'avoir un JS (encore) qui ajouterait un changement de vue (une bascule vue dépliée (l'actuelle), vue courte (à définir), par exemple juste des vignettes), à droite des grands blocs (À droite du titre "Illustrations" par exemple), pourrait être utile ?
3) Il y a toujours pour la 3.2 l'idée d'intégrer le plugin «Medoc» dans le plugin Medias également, afin d'avoir un cadre / modèle homogène pour l'insertion de documents. Il n'y a pas d'objection ?
1) Je viens de déposer un plugin nommé «Ordoc» sur la zone (pas encore
zippé mais cela viendra) qui permet (en JS uniquement pour l'instant) de
trier les documents liés à un objet éditorial (donc les illustrations,
portfolio ou documents) avec une petite icône pour cela.
Techniquement cela ajoute un champ "ordre" sur la table
spip_documents_liens et le JS envoie l'ordre des documents d'un bloc
(illustrations, portfolio ou documents) lorsqu'on déplace un élément à
une action SPIP qui enregistre l'ordre reçu (pour peu qu'il ait changé).
La remarque est sortie trois fois sur IRC : pourquoi ordre et pas rang ?
A voir si ça crée un effet de bord sur un autre champ dans les boucles.
J'aimerais bien un petit retour dessus. D'autre part, je me disais que
ça serait bien de l'intégrer directement au plugin Medias de SPIP
3.2-dev (le plugin actuellement est assez petit au bout du compte).
Qu'en pensez vous ?
Pas encore testé, mais au vu de le démo je suis déjà d'accord pour l'intégrer à Medias, c'est une demande récurrente de pouvoir trier les documents.
2) Autre demande qui arrive parfois c'est que dès lors qu'il y a plus
de, disons, 10 documents sur un article, la liste assez très longue, et
ce n'est pas toujours parfaitement pratique. Est-ce que d'avoir un JS
(encore) qui ajouterait un changement de vue (une bascule vue dépliée
(l'actuelle), vue courte (à définir), par exemple juste des vignettes),
à droite des grands blocs (À droite du titre "Illustrations" par
exemple), pourrait être utile ?
D'accord aussi, ça serait vraiment pratique.
Ça pourrait être développé et testé dans un autre plugin avant d'être intégré.
3) Il y a toujours pour la 3.2 l'idée d'intégrer le plugin «Medoc» dans
le plugin Medias également, afin d'avoir un cadre / modèle homogène pour
l'insertion de documents. Il n'y a pas d'objection ?
Aucune de ma part
Tout ça (et plus ?*) fera une belle avancée sur la gestion des docs dans la 3.2
Matthieu Marcillaud a écrit le 08/01/2017 à 14:50 :
Bonjour,
3 Points autour des médias de SPIP.
1) Je viens de déposer un plugin nommé «Ordoc» sur la zone (pas encore
zippé mais cela viendra) qui permet (en JS uniquement pour l'instant) de
trier les documents liés à un objet éditorial (donc les illustrations,
portfolio ou documents) avec une petite icône pour cela.
Techniquement cela ajoute un champ "ordre" sur la table
spip_documents_liens et le JS envoie l'ordre des documents d'un bloc
(illustrations, portfolio ou documents) lorsqu'on déplace un élément à
une action SPIP qui enregistre l'ordre reçu (pour peu qu'il ait changé).
Quelques remarques :
- sans le drag'n'drop, je fais déjà ça avec {par num titre} (et les crayons dans l'admin pour éditer rapidement les titres).
- et SPIP a une pseudo balise #RANG qui donne le numéro de titre
- mais {par rang} n'est pas disponible (cf pseudo balise)
Partant de là, il me semble qu'il serait plus pertinent/cohérent/respectueux de l'historique :
- de nommer ton champ rang
- de migrer automatiquement les numéros de titre dedans (pour tous les champs titre de la base, pas que ceux des docs, donc champ nom de spip_auteurs)
- et comme ça, on aurait enfin {par rang} et le drag'n'drop
- ... mais ça veut aussi dire qu'il faudrait généraliser ça à tous les autres objets de SPIP...
En tout cas, super piste !
PS : "Modifier" serait plus clair avec un autre terme : classer/réordonner
Matthieu Marcillaud a écrit le 08/01/2017 à 14:50 :
Bonjour,
3 Points autour des médias de SPIP.
1) Je viens de déposer un plugin nommé «Ordoc» sur la zone (pas encore
zippé mais cela viendra) qui permet (en JS uniquement pour l'instant) de
trier les documents liés à un objet éditorial (donc les illustrations,
portfolio ou documents) avec une petite icône pour cela.
Techniquement cela ajoute un champ "ordre" sur la table
spip_documents_liens et le JS envoie l'ordre des documents d'un bloc
(illustrations, portfolio ou documents) lorsqu'on déplace un élément à
une action SPIP qui enregistre l'ordre reçu (pour peu qu'il ait changé).
Quelques remarques :
- sans le drag'n'drop, je fais déjà ça avec {par num titre} (et les
crayons dans l'admin pour éditer rapidement les titres).
Mouais… c'est pas guère rapide… ET surtout si tu utilises 2 fois le même document (sur 2 articles) mais en voulant un tri différent, tu es cuit.
- et SPIP a une pseudo balise #RANG qui donne le numéro de titre
- mais {par rang} n'est pas disponible (cf pseudo balise)
C'était justement pour cela que je n'avais pas utilisé "rang" car j'avais peur d'un effet de bort (j'imaginais que "rang" était plutôt sur la table de l'objet éditorial, plutôt que sur une table de liens).
En regardant le code, je pense que tant qu'un champ "rang" n'est pas créé sur spip_documents directement, ça marcherait de mettre "rang" sur la table de liens. Mais est-ce que rang n'est pas fait pour aller directement un jour sur l'objet éditorial ? (plutôt que de mettre des numéros devant les titres ?).
Partant de là, il me semble qu'il serait plus
pertinent/cohérent/respectueux de l'historique :
- de nommer ton champ rang
- de migrer automatiquement les numéros de titre dedans (pour tous les
champs titre de la base, pas que ceux des docs, donc champ nom de
spip_auteurs)
Non non, je pense qu'on déborde là. Restons sur spip_documents(_liens).
- et comme ça, on aurait enfin {par rang} et le drag'n'drop
- ... mais ça veut aussi dire qu'il faudrait généraliser ça à tous les
autres objets de SPIP...
En tout cas, super piste !
PS : "Modifier" serait plus clair avec un autre terme : classer/réordonner
Heu. Le "Modifier" ouvre la modale de modification du document… c'est déjà là par défaut.
Matthieu Marcillaud a écrit le 08/01/2017 à 17:27 :
Matthieu Marcillaud a écrit le 08/01/2017 à 14:50 :
Bonjour,
3 Points autour des médias de SPIP.
1) Je viens de déposer un plugin nommé «Ordoc» sur la zone (pas encore
zippé mais cela viendra) qui permet (en JS uniquement pour l'instant) de
trier les documents liés à un objet éditorial (donc les illustrations,
portfolio ou documents) avec une petite icône pour cela.
Techniquement cela ajoute un champ "ordre" sur la table
spip_documents_liens et le JS envoie l'ordre des documents d'un bloc
(illustrations, portfolio ou documents) lorsqu'on déplace un élément à
une action SPIP qui enregistre l'ordre reçu (pour peu qu'il ait changé).
Quelques remarques :
- sans le drag'n'drop, je fais déjà ça avec {par num titre} (et les
crayons dans l'admin pour éditer rapidement les titres).
Mouais… c'est pas guère rapide… ET surtout si tu utilises 2 fois le même
document (sur 2 articles) mais en voulant un tri différent, tu es cuit.
Ah oui, j'avais pas percuté que c'est sur spip_documents_liens que tu stockais l'information.
(au passage, le statut illustration ou portfolio aurait carrément plus sa place sur cette même table, pour les mêmes raisons de ré-usage d'un document).
- et SPIP a une pseudo balise #RANG qui donne le numéro de titre
- mais {par rang} n'est pas disponible (cf pseudo balise)
C'était justement pour cela que je n'avais pas utilisé "rang" car
j'avais peur d'un effet de bort (j'imaginais que "rang" était plutôt sur
la table de l'objet éditorial, plutôt que sur une table de liens).
En regardant le code, je pense que tant qu'un champ "rang" n'est pas
créé sur spip_documents directement, ça marcherait de mettre "rang" sur
la table de liens. Mais est-ce que rang n'est pas fait pour aller
directement un jour sur l'objet éditorial ? (plutôt que de mettre des
numéros devant les titres ?).
rang n'a dans le cas précis des documents effectivement pas d'intérêt au niveau de spip_documents seulement de spip_documents_liens.
Partant de là, il me semble qu'il serait plus
pertinent/cohérent/respectueux de l'historique :
- de nommer ton champ rang
- de migrer automatiquement les numéros de titre dedans (pour tous les
champs titre de la base, pas que ceux des docs, donc champ nom de
spip_auteurs)
Non non, je pense qu'on déborde là. Restons sur spip_documents(_liens).
Vu comme ça, oui.
- et comme ça, on aurait enfin {par rang} et le drag'n'drop
- ... mais ça veut aussi dire qu'il faudrait généraliser ça à tous les
autres objets de SPIP...
En tout cas, super piste !
PS : "Modifier" serait plus clair avec un autre terme :
classer/réordonner
Heu. Le "Modifier" ouvre la modale de modification du document… c'est
déjà là par défaut.
Oups, dans ta vidéo, ça avait vraiment l'air d'être le label de la croix de drag'n'drop.
- J'ai modifié pour utiliser le champ "rang_lien" à la place de "ordre". Cf. discussion à côté "Ordre et rang sont dans un bateau".
- On peut déplacer un document en cliquant/glissant n'importe quel endroit du document, et pas uniquement la croix prévu. Il semble que ce comportement est plus facile d'usage (nicod)
Matthieu Marcillaud a écrit le 09/01/2017 à 16:22 :
- On peut déplacer un document en cliquant/glissant n'importe quel
endroit du document, et pas uniquement la croix prévu. Il semble que ce
comportement est plus facile d'usage (nicod)
Est-ce que ça ne va pas interférer avec le plugin centreimage ?
