Produits Entr'ouvert » w.c.s.

Juste un test chez moi pour voir ce que ça pourrait donner.

Frédéric Péters a écrit :

🐍 pour le Python et […] pour l'ezt ? (pas fan de case trop longue, à voir aussi assurer que la longueur reste fixe sur un changement de type)

Moi c'est un peu le contraire, je trouve qu'on devrait être assez "explicite" et ne pas utiliser d'icones qui ne veulent pas dire grand chose aux débutants. Donc je resterais bien sur mon idée de "Python" et "..[..].." avec même, quand c'est vide, un "[..] / Py" pour dire que le champ accepte les deux.

Ok c'est pas top, mais c'est mon idée alors je joue.

Bon c'est vrai que cette case au début peut paraitre un peu bizarre... peut-être en la mettant à la fin ?

Pour revenir ici, dans la suite de #24046 (UI pour les conditions), je verrais bien quelque chose de similaire ici (sélection explicite du contenu via un bouton sur la droite, avec en grisé dans le champ le type de contenu attendu); pour les conditions le nécessaire a été fait pour conserver de manière indépendante le format attendu, ça me semble plus compliqué à faire pour ces champs, du coup je composerais avec la contrainte du stockage sous forme de chaine de caractère.

On pourrait déterminer que le stockage se fait genre "$format$valeur", avec le nécessaire de compatibilité pour comprendre aussi =valeur comme étant $python$valeur, etc.

Après un temps sur cette idée $type$value, qui a permis de nettoyer le code, retirer les .startswith('=') à gauche et à droite, je suis revenu en arrière, pour rester sur la même syntaxe de stockage, le seul inconvénient étant de ne pas faire de distinction formelle entre texte simple et gabarit. (dans les avantages il y a l'utilisation pour les champs calculés dans un modèle odt, qui ainsi ne change pas).

Côté code pour montrer que ce n'est rien, je n'ai pas encore retiré la partie qui gérait $type$value, il y a ce bout dans form.py :

+        # after some time, switching format? (the benefit is to have distinct
+        # modes for text and template).
+        # self.value = '$%s$%s' % (value_type, value_content)

et ce bout dans workflows.py :

+        elif var.startswith('$') and var.count('$') > 1:
+            expression_type, expression_value = var.split('$', 2)[1:]

Bref, voici le patch, et je pense que c'est vraiment mieux de faire sans $type$value. (et j'en retirerai ces deux morceaux)

Pépin sur le style quand on est sur la gestion des données backoffice, screenshot ci-joint.

Corrigée la présence d'une chaine "Texte" et ce problème de style, j'ai aussi retiré la partie qui aurait géré $type$value.

commit bbe38a8fad115ac4f4afcde98aed8ce1dae7203d
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon May 28 14:39:59 2018 +0200

    general: update UI of expression widget to match condition widget (#19112)