dataviz: automatically refresh cells on filter change (#72465) #21
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/72465-dataviz-tenter-le-rafraichisseme"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Je cache le bouton submit côté cellule filtre mais pas côté formulaire de configuration d'une cellule car sinon ça casse le
display: flex
des boutons dupliquer/supprimer, on pourrait voir pour faire mieux dans un autre ticket.@ -65,0 +65,4 @@
$('select, input', 'form#chart-filters').change(function() {
if(loaded_cell_count == 0) {
$('form#chart-filters button.submit-button').click();
Je pense que c'est mieux d'utiliser l'event submit sur le form plutôt que de simuler un click sur le bouton :
$('form#chart-filters').submit();
je pense qu'il est même possible de récupérer le form d'un champs sans faire intervenir de dom :
this.form.submit()
Changé en faveur de submit(), par contre this.form.submit() (ou this.submit()) ne fonctionne pas, car ça soumet le formulaire alors qu'on ne veut pas vraiment (il y a un e.preventDefault() dans le handler).
@ -63,2 +63,4 @@
chart_cell.data('ajax-cell-url', new_url);
});
$('select, input', 'form#chart-filters').change(function() {
Pourquoi ne pas simplement ?
$('form#chart-filters').change(function()
Par mimétisme avec ce qui est fait côté BO, effectivement j'ai enlevé et ça fonctionne.
(côté BO ça crée une boucle infinie, pas 100% sûr à cause de quoi)
Je n'arrive pas à reproduire, c'est du côté de combo sur la cellule graph ?
C'est côté paramétrage de la cellule, sélectionner n'importe quelle donnée qui ne soit pas bijoe (genre « Démarches : Nombre de demandes »).
Pourquoi le cacher ? surtout via html/css. Si JS disfonctionne, il doit rester accessible.
Ensuite, il pourrait servir de feedback visuel pour indiquer à l'usager que le submit est parti.
(Mais je continue à parler d'un truc que je n'ai pas encore tester, je reviens)
0d3bc6f758
todb9cb5d1c8
C'est Stéphane qui me faisait remarquer que côté BO le rafraîchissement auto en laissant le bouton « Enregistrer » était ambigu, l'utilisateur n'est pas sûr que la cellule soit enregistrée à chaque rafraîchissement (alors qu'elle l'est). Enlever le bouton est un moyen simple de lever cette ambiguïté, mais tu préférerais sûrement un texte explicite à côté du bouton « Modifications enregistrées. » ?
En tout cas cet argument ne s'applique pas vraiment au bouton « Rafraîchir », je le remets ?
J'y ai pensé mais si le JS dysfonctionne le bouton rafraîchir ne fonctionnera pas non plus (ou alors on parle d'un dysfonctionnement juste du rafraîchissement auto ?).
ah bon, quel élement visuel indque à l'usager que le rafraichessement est effectif, que la requête a aboutie ?.
Si dans son champ de vision un graph est mis à jour, ok, mais ce n'est pas certain.
Une erreur peut aussi très bien se passer côté serveur, et rien n'indique alors que la requête a échouée.
Oui, un truc à réfréchir dans ce sens. Le bouton pourrait prendre un statut à l'envoie d'une requête et un autre statut provisoire au succès ou à l'échec.
Pour cela il faudrait eventuellement se pencher du côté de combo:refresh-graphs, pourquoi pas retourner un event combo:refresh-graphs-success et combo:refresh-graph-error et essayer d'être explicite à l'usager.
Mais comme on refresh plusieurs graphs, bref, pas forcement simple et pas forcement pour ce ticket.
En tout cas, masquer le bouton n'est pas suffisant en soit.
db9cb5d1c8
to9bf2e8bf05
OK merci pour les éléments de réflexion, j'ai retiré le masquage du bouton (et pour la suite, comme j'avais écrit en description, « autre ticket »).
@ -63,2 +63,4 @@
chart_cell.data('ajax-cell-url', new_url);
});
$('form#chart-filters').change(function() {
$('form#chart-filters')
utilisé 3x.Pour des questions de performance, ne pas parser 3x le dom. Parser 1x et stocker dans 1 `const form = $('#chart-filters');
Modif appliquée
9bf2e8bf05
tod2e6c02335
Bon, j'ai creusé la question.
Un vrai sac de noeud cause des events change qui se lancent de partout
Je vais tenter une explication.
1. Au chargement de la cell, un change se lance sur le select time-range (chartngcell_from.html l.16)
2. Tu ajoutes une fonction button.click (l.35) sur l'event change de tous les champs du tab general après 1. (c'est important le après, c'est ce qui fait que ça marche et ne pas boucler, tu déplaces cette function avant 1. et ça boucle). Il ne prend donc pas en compte le change de 1. (Alors que ma proposition de poser le change sur le form, si)
3. À la modification d'un champ, JS click sur le bouton qui va lancer une fonction définie dans combo.manager.js l.261 qui va envoyer le form via ajax et en cas de succès remplacer TOUT l'html des tabs de la cellule, y compris le JS de chartngcell_form.html (l.281).
4. Le JS nouvellement injecté va être joué et on repart à 1. en relançant un change sur time-range puis 2.
Donc ça marche, ton code est ok, et ma proposition est ko.
Mais j'ai comme un sentiment que tout cela est fragile.