API CVT Configurer : savoir gérer les champs "file" #4740

Open
opened 6 months ago by rastapopoulos · 4 comments
Owner

Une évolution intéressante serait que l'API automatique de configuration sache gérer les champs fichiers.

Actuellement on n'a pas de mécanisme simplifié permettant d'enregistrer des fichiers sans rapport avec l'éditorial, donc sans rapport avec la médiathèque (pas en spip_documents), sans coder soi-même à chaque fois une implémentation dédiée en PHP.

Le cas d'utilisation vraiment très courant me paraitre être pour les formulaires de config des plugins, notamment pour des images (mais pas que, ça pourrait être un son à jouer ou que sais-je).
Exemple IRL :

  • pouvoir configurer le plugin Favicon avec une image dédiée
  • pouvoir configurer un webmanifest pour une appli, qui attend aussi une icône dédiée
  • pouvoir configurer un squelette/thème qui attend telles et telles images propres à l'ergo/graphisme de ce thème (image d'entête, image de pied, etc)

Ma piste serait une augmentation de l'API CVT Configurer, pour qu'il sache aussi enregistrer les champs "file" et non pas juste les champs qui envoient un scalaire. Dans ce cas, ça enregistrerait le fichier dans un dossier permanent et public, donc dans IMG. Par exemple dans IMG/configurer/nom_du_form/fichier.png.
Possiblement une ou deux fonctions/balises permettrait de les récupérer facilement, que ce soit pour ré-afficher ce qui est déjà uploadé à côté du champ de config, ou pour les utilisations réelles ensuite dans le site.

Une personne NON dev, juste intégrateurice, serait donc capable en 5min de pouvoir configurer aussi des fichiers, pour son squelette/thème.

Une évolution intéressante serait que l'API automatique de configuration sache gérer les champs fichiers. Actuellement on n'a pas de mécanisme simplifié permettant d'enregistrer des fichiers sans rapport avec l'éditorial, donc sans rapport avec la médiathèque (pas en spip_documents), sans coder soi-même à chaque fois une implémentation dédiée en PHP. Le cas d'utilisation vraiment très courant me paraitre être pour les formulaires de config des plugins, notamment pour des images (mais pas que, ça pourrait être un son à jouer ou que sais-je). Exemple IRL : - pouvoir configurer le plugin Favicon avec une image dédiée - pouvoir configurer un webmanifest pour une appli, qui attend aussi une icône dédiée - pouvoir configurer un squelette/thème qui attend telles et telles images propres à l'ergo/graphisme de ce thème (image d'entête, image de pied, etc) Ma piste serait une augmentation de l'API CVT Configurer, pour qu'il sache aussi enregistrer les champs "file" et non pas juste les champs qui envoient un scalaire. Dans ce cas, ça enregistrerait le fichier dans un dossier permanent et public, donc dans IMG. Par exemple dans IMG/configurer/nom_du_form/fichier.png. Possiblement une ou deux fonctions/balises permettrait de les récupérer facilement, que ce soit pour ré-afficher ce qui est déjà uploadé à côté du champ de config, ou pour les utilisations réelles ensuite dans le site. Une personne NON dev, juste intégrateurice, serait donc capable en 5min de pouvoir configurer aussi des fichiers, pour son squelette/thème.

Depuis qu'on a des rôles de document en SPIP 3.3, ça pourrait peut-être être dans la médiathèque avec un rôle spécifique par image (genre prefixplugin_nomduchampfile) ?

Depuis qu'on a des rôles de document en SPIP 3.3, ça pourrait peut-être être dans la médiathèque avec un rôle spécifique par image (genre prefixplugin_nomduchampfile) ?
Poster
Owner
  1. Depuis quand on a des rôles pour les documents ? Ça c'est le plugin Rôles de documents et c'est pas du tout intégré en 3.3
  2. Les rôles c'est pour définir sur un lien "ce document est pour tel contenu", donc sur spip_documents_liens uniquement.

Là je parle bien de fichiers qui n'ont pas de rapport avec l'éditorial, qui ne sont liés à aucun contenu, et qu'il faut juste pouvoir retrouver suivant le name donné dans une config.

Un truc du genre :
formulaires/configurer_favicon => <input type="file" name="icone" /> => #CONFIG{favicon/icone} => chemin du fichier (où qu'on décide de le stocker par défaut)
formulaires/configurer_monsquelette => <input type="file" name="image_pied" /> => #CONFIG{monsquelette/image_pied}

1) Depuis quand on a des rôles pour les documents ? Ça c'est le plugin Rôles de documents et c'est pas du tout intégré en 3.3 2) Les rôles c'est pour définir sur un lien "ce document est <role> pour tel contenu", donc sur spip_documents_liens uniquement. Là je parle bien de fichiers qui n'ont pas de rapport avec l'éditorial, qui ne sont liés à aucun contenu, et qu'il faut juste pouvoir retrouver suivant le name donné dans une config. Un truc du genre : formulaires/configurer_favicon => `<input type="file" name="icone" />` => `#CONFIG{favicon/icone}` => chemin du fichier (où qu'on décide de le stocker par défaut) formulaires/configurer_monsquelette => `<input type="file" name="image_pied" />` => `#CONFIG{monsquelette/image_pied}`

À effectivement, j'avais mal compris le fonctionnement des rôles en 3.3 tel que tu le décris.

Sauf que je viens de regarder le contenu de la table spip_documents d'un site en 3.3 et je vois la colonne mode qui contient : image, document, logoon
Ce qui veut dire au passage qu'un fichier image ne peut pas être à la fois logo et image :(

Donc, je ne sais pas si tu parles de spip 3.3 ou du plugin Rôles documents.

Pour en revenir à ton idée de "file", il me semble qu'il faudrait en plus distinguer file et files.
Je m'explique :

  • pour la favicon, file parce qu'il n'y en a qu'une seule
  • mais pour des bannières, files parce qu'il peut y en avoir plusieurs

Ces 2 exemples correspondent à des usages que j'aurais aimé avoir et que j'ai remplacé par des mots clef avec leur logo :

  • un mot clef d'un titre spécifique pour file
  • un groupe de mots clefs avec des logos aux mots clefs du groupe pour files
À effectivement, j'avais mal compris le fonctionnement des rôles en 3.3 tel que tu le décris. Sauf que je viens de regarder le contenu de la table spip_documents d'un site en 3.3 et je vois la colonne mode qui contient : image, document, logoon Ce qui veut dire au passage qu'un fichier image ne peut pas être à la fois logo et image :( Donc, je ne sais pas si tu parles de spip 3.3 ou du plugin Rôles documents. Pour en revenir à ton idée de "file", il me semble qu'il faudrait en plus distinguer file et files. Je m'explique : * pour la favicon, file parce qu'il n'y en a qu'une seule * mais pour des bannières, files parce qu'il peut y en avoir plusieurs Ces 2 exemples correspondent à des usages que j'aurais aimé avoir et que j'ai remplacé par des mots clef avec leur logo : - un mot clef d'un titre spécifique pour file - un groupe de mots clefs avec des logos aux mots clefs du groupe pour files
Poster
Owner

J'ai rien compris :)

Donc, je ne sais pas si tu parles de spip 3.3 ou du plugin Rôles documents.

Euh je parle de rien moi c'est toi qui parle des rôles.

"file" c'est le type d'un champ HTML précis hein, donc si tu veux plusieurs images… bah tu mets plusieurs champs de config, si on parle bien de config (après un même champ, peut être un tableau, comme tout autre champ HTML : name="monchamp[]" mais c'est encore autre chose, à voir si ça doit savoir gérer ce cas aussi, pourquoi pas)

J'ai rien compris :) > Donc, je ne sais pas si tu parles de spip 3.3 ou du plugin Rôles documents. Euh je parle de rien moi c'est toi qui parle des rôles. "file" c'est le type d'un champ HTML précis hein, donc si tu veux plusieurs images… bah tu mets plusieurs champs de config, si on parle bien de config (après un même champ, peut être un tableau, comme tout autre champ HTML : name="monchamp[]" mais c'est encore autre chose, à voir si ça doit savoir gérer ce cas aussi, pourquoi pas)
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.