Produits Entr'ouvert » w.c.s.

Ack.

On est vraiment sûr que ça va pas écraser des trucs ? Parce que dans les variables de substitution, y'a beaucoup de n'importe quoi, non ?

Il ya site_name, site_theme, site_url, site_url_backoffice, site_lang, today, now, is_in_backoffice + ce qui est contenu dans le [variables] du site-options.cfg. Par rapport à ce que django fournit en standard il y a conflit sur "now".

Mais ce conflit existe déjà de toute façon pour le rendu des templates de page, qui reçoivent toutes les variables de substitution (pas seulement celles du publisher).

De greps sur la prod, "now" est utilisé façon "Le formulaire a été enregistré le [now]" ou "Votre demande a été réceptionnée le [now] par nos services" (pourrait prendre [form_receipt_data] [form_receipt_time]), pas trouvé de référence dans des workflows; si on voulait le retirer à mon avis on pourrait sans danger.

Voilà, c'est surtout parce que je ne suis pas fan de l'ajout des «variables». Et que ça demande, on le voit ici, de faire attention quand on va jouer des variables dans wcs.

Mais ce conflit existe déjà de toute façon pour le rendu des templates de page, qui reçoivent toutes les variables de substitution (pas seulement celles du publisher).

Je suis complétement passé à côté de ça. Je sais pas si c'est si gênant, mais j'ai quand même l'impression que les context processor doivent éviter de trop jouer au hasard dans le contexte. Est-il encore temps de revoir ça ? Genre, de ne pas poser tout le dictionnaire des substvars tel quel dans le contexte, mais plutôt de l'envoyer dans une variable « wcs_vars » ?

Et les ajouter via un préfixe, genre {'wcs': get_publisher().get_substitution_variables()} ou {'publisher': get_publisher().get_substitution_variables()} ?

Benjamin Dauvergne a écrit :

Et les ajouter via un préfixe, genre {'wcs': get_publisher().get_substitution_variables()} ou {'publisher': get_publisher().get_substitution_variables()} ?

Ouaip pour ce ticket, mais je proposais de généraliser l'affaire, de ne pas poser les variables wcs à la racine du contexte. C'est aussi parce que dans qommon.template.get_decorate_vars on termine par un vars.update(locals()) qui ne me mets pas en confiance. Mais, oui, cette idée dépasse le cadre de ce ticket, et j'aurais dû réagir plus tôt en relisant mieux 01b280aa2 (et à relire, je suis reperdu, trop vacancier)

Déjà pour ce ticket, je serai plus à l'aise avec {'wcs': get_publisher().get_substitution_variables()}

[...] C'est aussi parce que dans qommon.template.get_decorate_vars on termine par un vars.update(locals()) qui ne me mets pas en confiance. [...]

Cet appel à locals(), c'est septembre 2005; conservé au fil du temps à cause de ses défauts : on s'est trouvé à ne pas avoir de liste nette de ce qui a pu être utilisé dans des templates. En vrai, avec un peu d'attention, on doit pouvoir constituer cette liste, et ça me va bien d'avoir ce genre de nettoyage. Mais ailleurs.

Déjà pour ce ticket, je serai plus à l'aise avec {'wcs': get_publisher().get_substitution_variables()}

Mais ça fait perdre la compatibilité avec les templates rendus par les autres applications, où hobo met *_url (et toutes les autres variables qui peuvent y être définies) à la racine.

Du coup ici j'attendrais qu'on prenne le temps de discuter et sur le temps immédiat je limiterais à :

def publisher_context_processor(request):
    return {'publisher': get_publisher()}

(voire 'wcs_publisher' même si j'aime moins)

Comme ton besoin est "connaitre dans le rendu d'un template si on est dans le backoffice", c'est pas plutôt quelque chose comme wcs_request.is_in_backoffice dont tu as besoin ?

publisher.get_request.is_in_backoffice.

Perso j'aurai préféré un simple objet wcs_request ou quixote_request rendu par un context processor wcs.whatever.wcs_request qui serait à côté de django.template.context_processors.request

Mais publisher aussi ça peut aller (au passage je pense qu'on doit pouvoir renvoyer get_publisher au lieu de get_publisher(), Django est assez doué sur ces machins lazy)

Parfait, ack.