datasources: add the template type (#78777) #695
fpeters
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/78777-template-data-source"
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?
À part ça dans ce qu'il était noté dans le ticket, il y avait :
@ -574,0 +600,4 @@value = Template(data_source.get('value')).render(context=variables)except TemplateSyntaxError:get_publisher().record_error('Python data source (%r) gave a template syntax error' % data_source.get('value'),Pas Python.
ae1d1d77f9to300273aa55300273aa55to5a2ddba54c5a2ddba54cto1406c2db4b1406c2db4btobd15f02d5c7a5806bb5ftod535e49bfcJe sais bien c'est pour ça que cette PR était encore en 'wip' quand tu l'as commenté.
A part ça depuis ta relecture j'ai changé les choses : pas de nouveau type de data source, plutôt que celles de type jsonvalue acceptent un gabarit.
L'introduction d'un nouveau type m'a furieusement fait penser à la distinction texte/gabarit qu' on a finit par faire disparaître je ne sais plus où.
Aussi ça me semble plus lisible pour les utilisateurs : les sources de données de type jsonvalue, soit on y écrit directement du json, soit un gabarit qui va donner du json (cas d'usage de Steph), soit un gabarit avec une seule variable qu'on transforme en json via |json_dumps.
Tout ça me semble bien raccord.
d535e49bfcto0bb9984acaIl manque encore des choses pour le rafraîchissement automatique si un champ qui précède sur la page change et si le gabarit de la source de donnée fait usage de ce champ.
Je regarde ça, peut-être dans un ticket à part (aucune idée de la complexité).
WIP: datasources: add the template type (#78777)to datasources: add the template type (#78777)0bb9984acatofd507a983ffd507a983fto3a33d08b53Un commit de plus pour gérer le cas simple :
{{% if form_var_toto %}} ...Par contre pour pour la version
{{form_vat_toto_agendas|json_dumps}}ça ne fonctionne pas du tout. Sur ce gabaritField.get_referenced_varnamesne renvoie rien.Quand bien même je lui passerais juste
{{form_var_toto_agendas}}il me renverraittoto_agendasalors que je voudrais justetoto.Et j'imagine qu'on veut pas complexifier l'expression régulière avec un postfix spécifique 'agendas' .... bref pas de piste.
3a33d08b53to5cab2eb7eaJe me suis aventuré là dedans en commençant par un le patch ci-joint que je met ici pour mémoire. Mais ça ne suffit pas, j'ai passé un moment à creuser ça, je finis à tort ou à raison dans qommon.form.js et là je renonce.
Bilan des courses, avec les commits inclus ici la forme
{% if form_var_toto %}} ...écrire du json {% endif %}fonctionne sur une même page et sur deux pages différentes, la forme {form_vat_toto_agendas|json_dumps}} fonctionne sur deux pages différentes mais pas sur une même page.Et je vais m'arrêter là (en attendant relecture) sur ce ticket.
J'ai essayé de faire le lien entre les tests et la description du ticket mais je ne suis pas bien sûr, et le dernier commentaire semble dire que ce qui était imaginé dans le ticket, le {{form_var_foo_agendas|json_dumps}} ne marcherait pas s'il est mis sur la même page que le champ donnant "form_var_foo" ?
Je serais pour avoir dans les tests quelque chose de plus proche du besoin exprimé dans le ticket. Et éventuellement le test en xfail ou dans un commit séparé qui rappellerait qu'il faut faire marcher ça sur une seule page.
Je relis le diff en fichier attaché et je comprends que la difficulté serait sur la détection de la variable, en fait cette partie est totalement accessoire, et quand j'écris {{form_var_foo_agendas|json_dumps}} il peut tout à fait être lu
(sans trop savoir quelle nécessité au else, c'est évidemment mieux si ça peut marcher sans, qu'un résultat vide soit ok.
(reste que dans les tests je souhaiterais quand même quelque chose s'approchant davantage du besoin originel, c'est-à-dire la combinaison d'un champ avec une source de données allant chercher dans chrono une info et dessous un champ qui alimente sa liste de choix par un extrait de ce qui a été choisi dans le premier).
(cf demande de test spécifique ci-dessus)
5cab2eb7eato598f4ab9d4Voilà avec deux tests qui reprennent le cas d'usage chrono, un premier avec
{% if form_var_rdv %}{{ form_var_rdv_agendas|json_dumps}}{% endif %}qui passe.Un deuxième marqué xfail avec
{{ form_var_rdv_agendas|json_dumps}}.Dans le premier, pour simuler le comportement du js je fais
live_resp = app.post('/foo/live?modified_field_id=1', params=resp.form.submit_fields()).Malheureusement notre js ne passe pas de paramètre modified_field_id dans la requête, donc pour l'instant ça ne marche pas "en vrai" : https://dev.entrouvert.org/issues/82042
Je serais à dire qu'il pourrait être dégagé, c'est trop annexe et sans tout l'historique/commentaire on ne retrouvera pas pourquoi il a été ajouté.
598f4ab9d4to9fb1dd12d0Viré.
9fb1dd12d0to941ad44c51