Development #436
Affichage conditionnel sur une même page
0%
Description
Je rebondis sur la demande #435, car la demande me semble trop spécifique si on suit l'implémentation voulu par victor pour un coût en développement qui serait le même que quelque chose de plus générique et que victor évoques d'ailleurs, i.e. avoir un affichage/masquage conditionnel en temps réel sur la même page de n'importe quel champ, et donc forcément en javascript.
Je verrai bien un système ultra simple (on peut commencer par /([^=]*)==([^=]*)/ ) pour commencer du même genre que ce qu'on fait actuellement ("f15==oui") qui serait parsé et générerait un code javscript contrôlant l'affichage de n'importe quel champ d'une page..
L'important pour moi n'étant pas la complexité du langage proposé (juste l'égalité c'est parfait) mais l'aide à la rédaction:- qu'on écrive 1, oui, ==true, si le champ est booléan, ça marche,
- on affiche en commentaire la liste des champs disponibles,
- si la valeur proposée ne peut matcher avec aucune valeur du champ, on affiche un message d'erreur.
L'utilisation d'une syntaxe python ("f15 est vrai" ça le fait aussi) n'ayant pas non plus une grande importance. Encore une fois l'important étant qu'il soit difficile de se tirer une balle dans le pied avec ça, i.e une condition invalide (champ ou valeur qui a disparu) est juste ignorée par exemple, mais ne bloque pas l'utilisation du formulaire, elle la rend juste moins intuitive.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Thomas Noël il y a plus de 12 ans
Ca serait sympa, mais je vois déjà un problème : celui des champs obligatoires mais conditionnels (et ce cas viendra très vite)...
Pour arriver à quelque chose qui marche, il nous faudrait une condition compatible jajascript (pour l'affichage) et Python (pour la vérification du POST)... Je vois pas trop comment, sauf à prendre un langage pivot, mais je donne ma langue au caht (de Victor).
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Lié à Development #22738: Visibilité dynamique de champs dans une page ajouté
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Lié à Development #19752: Possibilité d'utiliser des champs (et non plus des pages) conditionnels ajouté
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Lié à Development #22106: Création paresseuse des variables de substitution ajouté
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Lié à Development #25541: ne pas générer le contenu potentiel d'une barre latérale lors d'une requête json ajouté
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Lié à Development #25601: ne plus marquer les conditions django comme expérimentales ajouté
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Fichier 0004-add-live-field-conditions-436.patch 0004-add-live-field-conditions-436.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Assigné à mis à Frédéric Péters
- Patch proposed mis à Oui
C'est maintenant disponible dans la branche https://git.entrouvert.org/wcs.git/log/?h=wip/22106-lazy-variables
Mis à jour par Thomas Noël il y a plus de 5 ans
Sur cette partie :
for field in submitted_fields:
if not field.is_visible(form_data, self.formdef):
del form._names['f%s' % field.id]
on peut avoir un KeyError sur le dev si le "live" a été lent à répondre, que le formulaire n'avait pas encore le bon affichage des champs visibles/invisibles lorsqu'on a cliqué sur le submit (j'ai ajouté un "time.sleep(2)" au début de live pour reproduire facilement).
Donc, plutôt,
for field in submitted_fields:
if not field.is_visible(form_data, self.formdef) and ('f%s' % field.id in form._names):
del form._names['f%s' % field.id]
A noter que si le live est lent à répondre, qu'un champ n'a pas eu le temps de s'afficher mais qu'il avait un pré-remplissage, c'est ce dernier qui est pris en compte, ben oui c'est comme ça voilà (me semble moins simple à corriger, et pas très grave).
Discuté sur jabber : si une condition est un webservice.foo ou data_source.bar et que ces derniers font référence à des form_var_xxx alors ça ne passe pas, car il n'y a pas de form_var_xxx détecté. On peut vivre sans pour commencer.
Mini truc sur la forme, cette partie :
for field in displayed_fields:
if field.varname not in live_condition_fields:
continue
form.get_widget('f%s' % field.id).live_condition_source = True
pourrait gagner quelques octets ainsi :
for field in displayed_fields:
if field.varname in live_condition_fields:
form.get_widget('f%s' % field.id).live_condition_source = True
(voir même
form.get_widget('f%s' % field.id).live_condition_source = field.varname in live_condition_fields mais bon, doucement)Mis à jour par Thomas Noël il y a plus de 5 ans
Note: dans mes tests, pas de condition possible dépendante de la valeur d'un champ de type fichier (a priori parce que le widget est vraiment spécifique).
Mis à jour par Frédéric Péters il y a plus de 5 ans
Note: dans mes tests, pas de condition possible dépendante de la valeur d'un champ de type fichier (a priori parce que le widget est vraiment spécifique).
Branche à jour pour gérer les champs fichiers.
Mis à jour par Thomas Noël il y a plus de 5 ans
- Statut changé de Solution proposée à Solution validée
- Priorité changé de Bas à Normal
Ack
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 1e852f8d881aa852b5bb30300833d49ef1091baa
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Sat Jul 28 20:55:26 2018 +0200
add live field conditions (#436)
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
add live field conditions (#436)