Development #448
ajouter des "vues" sur les formulaires
0%
Description
Actuellement, on peut voir les données d'une réponse sous une forme assez "brute" (via une URL http://serveur/categ/form/1/)
Il serait utile de pouvoir programmer d'autres types de vues :
- pour afficher plus "joliment" sinon plus logiquement les données
- pour impression (ou transformation PDF rapide) par les agents
On pourrait imaginer que chaque formulaire puisse disposer d'un ensemble de vues, qu'on pourrait appeler par une URL du type : http://serveur/categ/form/1/?view=nom. Ces vues seraient programmable par l'administrateur, quitte à ce qu'il sache faire un minimum de HTML (ou autre format pas trop complexe à documenter et utiliser).
Une vue serait définie par :
- son nom (et si le nom est vide, alors ça devient la vue par défaut)
- le mime type de sortie : html par défaut, mais on peut imaginer txt, xml, json, pdf, ...
- le template, pour rendre la vue
(demande formulée par Echirolles lors de la formation de ce jour, transmise par Victor et traduite par Thomas)
Demandes liées
Historique
Mis à jour par Thomas Noël il y a presque 13 ans
+ éventuellement, pour chaque vue : les rôles qui peuvent y accéder
Mis à jour par Frédéric Péters il y a presque 13 ans
- Statut changé de Nouveau à Solution déployée
Quel rapport cette demande aurait-elle avec #258 ? (parce que quand je ferme des bugs comme étant dupliqués, on m'en veut)
Mis à jour par Thomas Noël il y a presque 13 ans
A mon avis, on doit pouvoir faire d'une pierre deux coups...
Mis à jour par Thomas Noël il y a presque 13 ans
Je pensais ajouter des "vues" sur un formulaire. Ces vues sont définies par l'admin.
On peut alors afficher une réponse à un formulaire selon les différentes vues disponibles pour le formulaire donné.
Chaque vue a :- un nom
- un template = un textarea dans un format à définir (txt, html, rtf?) [mais on peut aussi imaginer un fichier uploadé si on disposé d'une methode pour remplacer les champs, genre un document LibreOffice]
- les rôles qui peuvent afficher la vue (l'expéditeur, les destinataires, un rôle particulier, tout le monde, etc)
- les statuts dans lesquel la vue est activée (typiquement : une vue "courrier pour dossier accepté" n'est visible que dans le statut "accepté")
- un processeur de sortie si besoin (pour générer du pdf depuis le html, par exemple)
- dans le backoffice quand un agent regarde un formulaire (liens dans la colonne de droite)
- dans /myspace pour l'utilisateur concerné (un lien vers chaque vue qu'il a le droit de voir [en fonction des rôles définis dans la vue et du statut de sa demande])
- s'il y a une vue "default" en html, c'est celle qu'on affiche quand on présente le formulaire à la personne (au lieu de la simple énumération exhaustive des champs actuels)
- s'il y une vue "backoffice" en html, c'est celle qu'on affiche pour les agents
- s'il y une vue "details" en txt, c'est celle qui est utilisée pour le champs [details] des mails à envoyer.
Mis à jour par Benjamin Dauvergne il y a presque 13 ans
Donc je propose ces nouvelles URLs:
- /admin/forms/[form.id]/views - configuration des vues pour une formulaire données
* /admin/forms/[form.id]/views/new - créer une nouvelle vue
Nom: [____________________________] Mimetype du template: [ RTF ^] | HTML | | TXT | | CSV | ( n'a pas d'importance en cas de moulinette ) Template: [____________________________] [____________________________] [____________________________] [____________________________/ [ Utiliser un fichier comme template ] Champs disponibles : <ici on récapitule la liste des champs pour aider, éventuellement on peut ajouter du js pour ajouter un champ quand on clique dessus, ça c'est cadeau>, peut-être aussi un lien vers une doc de notre outil de template (il sait faire un peu plus que du remplacement de variables, il y a des boucles et des conditionnelles) Accessible aux rôles : [ Agent ^] [+] Si le statut est : [ _____ ^] [+] Moulinette: [ _____ ^] [ Créer ] [ Annuler ]
- /admin/forms/[form.id]/views/[views.id] - éditer une vue * /admin/forms/[form.id]/views/[views.id]/delete - supprimer une vue
Les moulinettes sont des scripts exécutables dans /usr/share/authentic/processors/ et/ou /var/lib/wcs/<domaine>/processors. Il retourne le mime/type sur la première ligne puis le contenu.
L'entête du fichier contient des metadatas, sinon c'est le nom du fichier qui est utilisé.
# name: HTML to PDF converter
# name: {fr}convertisseur de HTML vers PDF
# description: Use webkit2pdf blabla.... exemple of printing stylesheet: http://....
Mis à jour par Thomas Noël il y a presque 13 ans
Moi je pensais à des moulinettes en python "pur et dur", i.e. des fonctions à qui on envoie les infos (le résultat du template, le user, le formdata, etc...) et qui renvoie un mime, un contenu (ou des exceptions...).
Mis à jour par Benjamin Dauvergne il y a presque 13 ans
redmine@entrouvert.com écrivait:
La demande #448 a été mise à jour par Thomas Noël.
Moi je pensais à des moulinettes en python "pur et dur", i.e. des
fonctions à qui on envoie les infos (le résultat du template, le user,
le formdata, etc...) et qui renvoie un mime, un contenu (ou des
exceptions...).
KISS, je préfère les pipes si un besoin plus important ne se fait pas
sentir.
Mis à jour par Frédéric Péters il y a presque 13 ans
C'est formidable mais j'ai l'impression de voir deux astronautes s'envoler; et je me dis que sur une demande concrète, avec une échéance courte et payée 1 ou 1½ journée de dev, ce n'est pas le moment.
"la publication de la demande vers un modèle (courrier en particulier)", voilà ce qui est demandé, ça n'enlève rien à l'idée de "vues" sur un formulaire, sauf l'urgence, ce qui est quand même pas mal; je pense donc laisser cette demande trainer, et ouvrir une nouvelle, pour le besoin précis.
C'est la demande #455.
Mis à jour par Frédéric Péters il y a environ 12 ans
- Statut changé de Solution déployée à Rejeté
Discuté avec Thomas, ces histoires de vues arriveront, via le ticket 1213 et sa suite.