Produits Entr'ouvert » w.c.s.

Est-ce qu'on permettrait plusieurs conditions de sortie ? (parce que ça pourra vite être une grande formule pénible) pour éventuellement lier chaque condition à un champ de la page où sera posée le message d'erreur...

(et je sais que la réponse sera "non, on fait comme la condition d'entrée", mais bon, voilà, j'ai dit)

Oui, on prévoit plusieurs sorties. (tableau de {'condition': '...', 'error_msg': '...'}).

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

tableau de {'condition': '...', 'error_msg': '...'}

Donc éventuellement « {'condition': '...', 'error_msg': '...', 'fields': [...]} » avec "field" qui serait présenté en UI comme un select multiple des champs de la page. Ouaip, bon.

(note en coin de tête : ça serait bien aussi d'avoir la possibilité de mettre des conditions d'entrée multiples, à cette occasion, histoire d'éviter les conditions à rallonge à cause d'un ou deux "and")

Je ne vois pas ce que tu mettrais dans "fields". (j'aurais au pire imaginé le champ sur lequel attacher l'erreur si elle survient, mais là encore ça ne serait qu'un seul champ)

Et donc en relisant plus haut, un peu oui attacher le message à un champ. Et je dis non, que les messages s'attacheront à la page.

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

Je ne vois pas ce que tu mettrais dans "fields". (j'aurais au pire imaginé le champ sur lequel attacher l'erreur si elle survient, mais là encore ça ne serait qu'un seul champ)

Oui, c'était « fields=['11', '12'] » pour dire « quand cette condition n'est pas remplie, mettre le message d'erreur sur les champs 11 et 12 »

Pas de soucis si y'a une impossibilité (j'ai pas regardé le code et même pas trop reflechi)

(j'ai juste relu, pas testé)

Donc sur le principe tout me parait conforme à l'attente.

Sauf : pour ne pas avoir les mêmes soucis actuellement avec les conditions de page ou de certains workflows, je préférerais qu'un RuntimeError soit considéré comme False et, donc, déclenche l'erreur.

Ack