Produits Entr'ouvert » w.c.s.

Sauf erreur de ma part, les conditions sont des expressions Python, et peuvent donc être très génériques, surtout depuis qu'on peut y utiliser les variables de substitution (genre "form_var_champnom.upper().startswith('T')" pour savoir si un champ commence par un 'T'). Très difficile à rendre, sauf à faire un peu trop cliquodrome.

Je serais d'avis d'avoir une aide en ligne avec quelques exemples classiques pertinents.

redmine@entrouvert.com écrivait:

La demande #325 a été mise à jour par Thomas Noël.

Sauf erreur de ma part, les conditions sont des expressions Python, et peuvent donc être très génériques, surtout depuis qu'on peut y utiliser les variables de substitution (genre "form_var_champnom.upper().startswith('T')" pour savoir si un champ commence par un 'T'). Très difficile à rendre, sauf à faire un peu trop cliquodrome.

Je serais d'avis d'avoir une aide en ligne avec quelques exemples classiques pertinents.

Au pire on peut faire une interface de ce genre, mais c'est peut-être du
temps passé pour rien si l'aide est suffisante:

[ ] Condition simple  
         Champ: [^ Raison de la demande        ] 
     Opération: [^   contient ]
                |       égale |
                | terminé par |
                '_____________'
        Valeur: [_______________________________________]

[X] Condition complexe (Expression Python)
                [_______________________________________]

[10:04:21] <fpeters> on peut travailler à faire l'inventaire exhaustif des expressions aujourd'hui utilisées.

serait déjà une bonne chose

Mon avis c'est qu'on devrait déjà travailler à signaler les erreurs prévisibles au niveau ezt et expressions:

• on devrait pouvoir depuis un workflow obtenir la liste de toutes les variables comnunes (même nom, même type) à tous les formulaires liés, si pas de formulaire lié uniquement les variables "de base" (celle qu'on a si un formulaire ne contient aucun champ) ; à voir si ça bloque un usage actuel (même nom de variable pour un champ texte dands un formulaire backoffice qui est un champ item dans un formulaire frontoffice);
  • cela implique qu'il faut toujours avoir un formulaire avant de démarrer le développement d'un workflow complexe, sinon on a aucune variable disponible dans le workflow (mais pour des workflow de base/génériques ce n'est pas un souci)
• on devrait pouvoir au niveau d'un workflow ou d'un formulaire lancer un check syntaxique+typage qui vérifie que toutes les expressions et templates ne référence que des variables définis (il y a une limite bien sûr, on ne sait pas forcément la structure de ce qu'il y a dans une variable et donc on doit s'arrêter au premier déréférencement, i.e. form_var_xxx_raw on peut vérifier que c'est possible, form_var_xxx_raw.zzz on ne saura qu'au runtime si cela existe)
• on affiche immédiatement au niveau de la fabrique de formulaire ou de la fabrique de workflow les erreurs trouvées avec des liens vers les pages où la correction doit être faite, une erreur ne doit pas rester cachée au fond d'un formulaire ou d'un workflow
• lors de la définition d'un template ou d'une expression on refuse immédiatement toute expression référencent une variable inconnue ou non commune à tous les formulaires ( et on signale si elle est inconnue ou absente de seulement un ou plusieurs formulaires liés)
• on fournit une aide à la saisie pour les champs expression et template, i.e. on propose une liste des variables complètes et à jour (via le mécanisme de la première puce)
• on doit aussi fournir dans l'aide contextuelle des exemples immédiatement utilisables (on explique qu'on peut faire des or, and, ==, [is xx ee], etc..)

On peut travailler sur un assistant pour produire des expressions python¹ mais pour moi ça demande la même machinerie que ce que je propose et donc il faut faire ce travail préalable avant d'envisager de faire quoi que ce soit de plus simple.

¹ ce genre de bidule http://i.stack.imgur.com/nzmgJ.png

Je dévie mais un coté intéressant à considérer que des formulaires liés à un même workflow ont forcément des variables communes c'est qu'on pourrait coté statistiques exploiter cette logique pour faire des statistiques par workflow (au niveau postgresql, formdata_xxx hérite de formdata_workflow_yyy qui hérite de formdata).