Produits Entr'ouvert » Combo

Si fonctionnellement c'est ok, il restera à voir comment faire communiquer les cellules entre elles.

Bon pour la communication j'ai 1 approche et 2 implémentations.

L'approche c'est de faire placer par publish_page() dans le contexte de rendu un variable common contenant un dictionnaire, dictionnaire qui pourra être mis à jour par les cellules au fur et à mesure du rendu, donc une cellule plus haut dans une page pourra communiquer avec une cellule plus bas.

• ajouter partout un paramètre context à get_extra_cell_context() (avec pour certains appels, context=Context() car il n'y en a pas à cet endroit, dans les calculs de feed et de menu il me semble),
• ajouter une nouvelle méthode modify_context(Context) -> Context à CellBase appelé sur l'objet context dans le template tag render_cell

On pourrait vouloir cette cellule dans une barre latérale et les graphiques dans la zone centrale et du coup on ne serait pas dans une situation avec "une cellule plus haut dans une page".

Dans ce cas le seul moyen que je vois c'est de faire une première passe sur toutes les cellules de la page en appelant une méthode modify_context() (plus besoin d'initialiser le common dans publish_page, puisque qu'on a plus le problème du context.push() fait implicitement dans template.render_to_stirng), puis ensuite de faire le render final.

Il faudrait passer aussi avoir les appels aux cell.modify_global_context() quand on fait le rendu d'une cellule unique dans ajax_page_cell, il me semble.

Et à profiter de ça, plutôt qu'un rechargement global de la page, les différentes cellules pourraient être rechargées.

Le combo.parameters-cell.js pourrait aller directement dans le combo.public.js, et vu le point précédent, ça pourrait juste être la création de la query string et puis les appels à combo_load_cell avec l'url + la query string.

Le modify_global_context il est appelé sur toutes les cellules, même celles qui ne sont pas visibles à l'usager. Comme de mon côté j'imaginais plusieurs ParametersCell sur la page, avec un contenu différent matchant la visibilité (i.e. une cellule "Paramètres Clapiers" avec juste le choix Clapiers, et limitée aux agents Clapiers), je me disais qu'il faudrait passer uniquement sur les ParametersCell visibles. (mais peut-être ton plan est-il différent sur cet aspect).

(en passant, à ce compte, la cellule "Paramètres Clapiers", ayant une seule option, n'aurait même pas besoin d'être affichée).

Je ne suis jamais bien fan de champs json pour paramétrer, on pourrait avoir un widget qui fasse tableau deux colonnes, ligne/valeur ? (ça peut être galère et on peut mettre de côté ça, en échange d'un XXX dans le code)

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

Il faudrait passer aussi avoir les appels aux cell.modify_global_context() quand on fait le rendu d'une cellule unique dans ajax_page_cell, il me semble.

Ouaip.

Et à profiter de ça, plutôt qu'un rechargement global de la page, les différentes cellules pourraient être rechargées.

D'ac je vais regarde à ça.

Le combo.parameters-cell.js pourrait aller directement dans le combo.public.js, et vu le point précédent, ça pourrait juste être la création de la query string et puis les appels à combo_load_cell avec l'url + la query string.

Je ne sais pas si c'est déjà fait mais effectivement il faut que je prévois de passe la qs dans le code de mise à jour/chargement des cellules ajax lors des appels à combo-load_cell dans tous les cas (je ne vais pas essayer de savoir si il y a une cellule paramètre ou pas dans la page je pense, le JS sera le même pour tous les chargements).

Le modify_global_context il est appelé sur toutes les cellules, même celles qui ne sont pas visibles à l'usager. Comme de mon côté j'imaginais plusieurs ParametersCell sur la page, avec un contenu différent matchant la visibilité (i.e. une cellule "Paramètres Clapiers" avec juste le choix Clapiers, et limitée aux agents Clapiers), je me disais qu'il faudrait passer uniquement sur les ParametersCell visibles. (mais peut-être ton plan est-il différent sur cet aspect).

Oui mon plan c'est d'utiliser le champs "roles" du paramétrage JSON pour limiter la visibilité de certains choix, ça me semble plus simple à configurer que d'avoir 1 cellule paramètre par commune, pour Clapiers on aurait visible les choix "rien", "Pôle de clapier", "Clapiers", pour un admin du pôle on aurait "rien", "Pôle x", toutes les villes du pôle X (j'imagine), ça donne un truc comme:

[
   { "name": "Pole X",
     "roles": ["Pole X", "Clapiers", "Cournonteral", ..],
     "value": ...
   },
   {
     "name": "Clapiers",
     "roles": ["Pole X", "Clapiers"],
     "value": ...
   },
  {
     "name": "Cournonteral",
     "roles": ["Pole X", "Cournonteral"],
     "value": ...
   },
   etc..
]

(en passant, à ce compte, la cellule "Paramètres Clapiers", ayant une seule option, n'aurait même pas besoin d'être affichée).

Si parce que j'ajoute toujours une option "rien" en plus, coté cubes dans ce cas c'est le filtre par défaut de la cellule cube qui est utilisé (pour Montpellier ce serait statistiques gloables tous pôles dans ce cas).

Je ne suis jamais bien fan de champs json pour paramétrer, on pourrait avoir un widget qui fasse tableau deux colonnes, ligne/valeur ? (ça peut être galère et on peut mettre de côté ça, en échange d'un XXX dans le code)

Oui c'est galère, je préfère fortement borné le schéma JSON avec de la validation pour permettre une migration plus facile vers des formulaires ensuites.

Ça m'irait bien d'avoir un attribut vary_on_parameters = False sur les cellules, voire même quelque chose de plus spécifique, genre vary_on_parameters = ['cube-'].

Je ne suis pas sûr de capter ce qu'on n'a pas encore; mais déjà, là, même si c'est juste booléen dans le template, au niveau de la définition des cellules, ça pourrait être une liste vide pour le CellBase et une liste ['cube-] pour les cellules Cube, me semble-t-il. (et retirer le .startswith js en attendant qu'il serve).

Je n'arrive toujours pas à comprendre quel morceau coince.

D'un côté, tu remplis la query string avec des cube-xxx, de l'autre on a maintenant un vary = ['cube-']; en mettant cette info dans un data-whatever, on a ce qu'il faut. (mais donc je passe sans doute à côté d'un truc, faudrait que je relise attentivement les patchs)

Et non justement je ne met rien dans la querystring, je met juste parameters-cell-1-choice=Clapiers et c'est la cellule dans modify_global_context() qui convertit cela en 'cubes-cut-commune': 'CLAPIERS', je ne permet pas de passer librement les filtres sinon on pourrait les forger.

ok, merci pour l'explication.

Dans 0002-add-a-modify_global_context-to-CellBase-9596, pourquoi la complication pour le "Cell can pass data through its own dict", ça correspond à quelle situation ?

J'essaie d'appliquer et de tester tout ça rapidement.

Je n'avais pas envie de recréer le formulaire une deuxième fois dans get_extra_cell_context() en plus de la construction qui est déjà faite dans modify_globale_context() car en plus il aurait fallu que j'extrais la requête depuis le contexte qui des fois n'y est pas, alors j'ai préféré le stocker dans une variable temporaire dans self._form. Mais ça suppose que l'objet cellule passé à modify_global_context() soit toujours le même que celui passé à get_extra_cell_context(), donc dans ajax_page_cell quand j'ai du implémenter la même chose j'ai eu le problème que l'objet cellule est récupéré deux fois, une fois pour les appels à modify_global_context() et une autre fois pour le rendu.

Il y a une tabulation dans 0005.

Dans 0002-add-a-modify_global_context-to-CellBase-9596, la comparaison se fait sur cell.pk, ça devrait être sur cell.get_reference() (pour prendre en compte le type de cellule aussi).

-        if other_cell.pk != cell.pk:
+        if other_cell.get_reference() != cell.get_reference():

Il y a dans data/themes/gadjo/templates/combo/placeholder.html qui ne me semble plus nécessaire. (et s'il est laissé en place il faut le modifier pour prendre en compte le vary_on_parameters.

Dans le json (ou un vrai champ), pourrait-on ajouter la possibilité de définir le libellé de l'absence d'option, pour permettre "Métropole" plutôt que "---" ?

Si c'est possible (et ça me semble l'être), on peut pousser 0003-pass-querystring-when-loading-cells-through-ajax-959.patch de façon isolée, dès maintenant ? (pour #9681).

Voilà, je viens de pousser ce commit particulier.