Jeudi 9 juillet, discussion avec Thomas, Naïma, Fred, Sergheï sur base d'un message de Thomas appelant à homogénéiser/rationnaliser les pratiques en termes de conception/réalisation de workflows/formulaires comme on on l'a fait (et continue de le faire) pour le code. Il en ressort un certain nombre d'idées un peu en vrac dont je ne sais pas encore ce qu'on va faire (vu qu'il y a d'autres urgences). Mais il faut qu'on dise à Naïma si elle doit tenir compte de ses potentielles évolutions ou pas dans l'écriture de la doc (a priori pas, elle tient compte uniquement de l'existant).

h1. Généralités

* Fiche d'aide à la dématérialisation (qui est à la fin de la réponse Alfortville, en annexes) à inclure dans la doc utilisateur que va faire Naïma.

* Utiliser des noms de variables explicites (code_postal plutôt que CP) en minuscule, sans accentuation, avec caractères alphanumériques + underscore uniquement.

* Il faut constituer un index des noms de variables pour les champs les plus classiques (pour pas qu'on ait une fois "rue_adresse", une fois "adresse_rue, etc.).

* Bonnes pratiques : quand est-ce qu'on utilise tel type de champs (liste à choix multiple, case à cocher, etc.) ? Naïma regarde s'il y a des trucs qui existent déjà. Pas facile à documenter à mon avis.

h1. Formulaires

* Plutôt que d'utiliser des "modèles" de formulaires (désactivés) pour importer des champs, on pourrait avoir de véritable blocs de champs pré-conçus, n'apparaissant pas dans la liste des formulaires. Lors que ce bloc est mis à jour, tous les formulaires qu l'utilisent sont automatiquement mis à jour.

* Écran d'édition d'un formulaire : pouvoir manipuler les champs directement sur la page d'accueil du formulaire (supprimer la page édition des champs). Et si possible pouvoir masquer les informations générales du formulaires quand on est en train d'éditer les champs (accordéon).

* Ajouter un type de champs "bloc de champs" pour remplacer les tableaux dynamiques qui sont pas terrible. Les champs contenus dans le "bloc de champs" pourrait s'afficher en décrochage (comme les champs à l'intérieur d'une page) et sur l'interface publique on aurait un bouton "ajouter" à la fin du bloc pour permettre à l'usager d'ajouter un nouveau bloc identique. Une option du "bloc de champs" permettra de dire dire combien de fois il s'affiche par défaut.

h1. Workflows

* Indiquer dans la doc que les WF c'est de la logique algorithmique et qu'il faut faire attention. Que plus ils seront complexe plus ils seront difficile à faire évoluer et qu'il est donc important de penser simple.

* Documenter comment on teste un WF (plusieurs comptes, plusieurs navigateur, plusieurs emails, plate-forme de test).

* Le dynamic dispatch va permettre d'éviter la prolifération de workflows "étagères" comme celui que j'ai fait à Montpellier pour les piscines : on juxtapose un statut par changement d'attributaire au lieu d'avoir une opération unique permettant de gérer correctement la chose.

* Il faut se pencher sur le problème des statuts qui se résument à quelques actions et un changement automatique (Thomas). Comme le statut "juste envoyé".

* On doit concevoir des actions de workflows plus haut niveau, plus métier, et les documenter à travers des exemples qui alimenteront la documentation générique.