Development #19113
distinguer les champs où une expression python est attendue
0%
Description
Dans la foulée de #19112, sur les endroits où du Python est attendu (par exemple les conditions), avoir un widget spécifique PythonExpressionWidget qui précède le champs avec une indication "Python".
Fichiers
Historique
Mis à jour par Thomas Noël il y a plus de 6 ans
- Fichier 0001-admin-add-a-python-expression-widged-use-it-in-page-.patch 0001-admin-add-a-python-expression-widged-use-it-in-page-.patch ajouté
- Fichier Capture d_écran de 2017-10-02 23-01-08.png Capture d_écran de 2017-10-02 23-01-08.png ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Sur le modèle de ComputedExpressionWidget, mais dédié au Python. Je factorise à cette occasion un peu de code et de css.
Pour que le patch ne soit pas vide, j'utilise ce widget sur le champ Page, copie d'écran jointe.
À l'usage, plus tard, il y aurait peut-être des types de confusion à ajouter en warning, pour l'instant ça prend juste les trucs avec des [xxx] ; on pourrait fait un warning si l'expression commence par un [ (usage valide très rare à mon avis dans wcs), ou si elle contient un [end], un "vars" sans parenthèses, etc.
Mis à jour par Thomas Noël il y a plus de 6 ans
Frédéric Péters a écrit :
Plutôt que Python, 🐍 ?
Amusant, mais est-ce assez clair ? J'avoue que j'ai une préférence pour l'explicite "Python", mais je veux bien l'avis de non techs. Ok qu'un gros "Python" ça mange bizarrement le début du champ, peut-être l'indicateur pourrait se retrouver tout à droite.
Mis à jour par Benjamin Dauvergne il y a plus de 6 ans
On a vraiment besoin de dire aux gens que c'est du Python... On peut dire le langage d'expression de w.c.s., actuellement il se trouve que c'est du python. Mais si on était amené à restreindre ça à un moment (pour simplifier la vérification syntaxe, etc.. i.e. ce serait un sous-ensemble de python, pas le droit d'écrire 2**10000000000 par exemple, qui fera craquer un worker w.c.s. à coup sûr) ça deviendrait moins vrai.
Idées moches:
[Expression][...] [Template][....] [Template/=Expression][ .... ]
Mais bon ce qui m'intéresserait plus c'est qu'en cliquant sur Template/Expression on ait une mini page d'aide avec la syntaxe et des exemples, à la redmine (voir éditeur du langage de formatage de redmine).
Mis à jour par Benjamin Dauvergne il y a plus de 6 ans
Ça m'irait que le code de validation d'une expression soit tout de suite factoriser dans un qommon.misc.validate_python_expression(expression), qu'on puisse le faire évoluer et qu'on en bénéficie partout. Ce qui m'embête c'est qu'avec une API web globale comme cela on ne va pas pouvoir bénéficier du contexte plus tard (i.e. valider que l'expression ne contient pas de référence à des variables qui n'existent pas par exemple), peut-être qu'on pourra passer des paramètres plus tard à l'API (genre ?workflow_id=xxx[&form_id=xxx]).
Mis à jour par Thomas Noël il y a plus de 6 ans
L'objet de ce patch est d'indiquer aux gens ce qui est attendu dans le champ (suite à des remarques des collègues, mais aussi de rochefort, par exemple). Si on met "expression" ça ne va vraiment pas aider, ça ne veut rien dire. En fait c'est mon idée, mais je pense qu'on est (les dev) mal placés pour répondre. Sans doute quelque chose à discuter calmement à l'eocamp.
Mis à jour par Thomas Noël il y a plus d'un an
- Statut changé de En cours à Fermé
- Planning mis à Non
Solution : on ne fait (fera) plus que partout du Django.