Je devrais vérifier, mais je pense que cela devrait fonctionner:

<h2>locals()</h2>
<pre>{{ locals() }}</pre>
<h2>globals()</h2>

... https://stackoverflow.com/questions/3398850/how-to-get-a-list-of-current-variables-from-jinja-2-template

@mitsuhiko de https://stackoverflow.com/a/13757358/188833 :

import jinja2

@jinja2.contextfunction
def get_context(c):
 return c

app.jinja_env.globals['context'] = get_context
app.jinja_env.globals['callable'] = callable

pour le débogage, par exemple, pyramid_debugtoolbar peut afficher le contexte du modèle si la fonction d'affichage - correctement abstraite à mon humble avis - renvoie simplement un objet de contexte (par exemple, dict, OrderedDict)

• https://github.com/Pylons/pyramid_debugtoolbar
• https://westurner.org/wiki/awesome-python-testing#pyramid

cas d'utilisation

Mon cas d'utilisation ici passe quelques arguments d'un utilitaire CLI à un modèle jinja2 (où j'aimerais définir les valeurs par défaut dans le modèle (par exemple pour Dockerfiles (sans autoescape , de toutes choses))

Ce que j'aimerais faire, c'est

{% set ENVVAR=context.get('ENVVAR', 'DEFAULT') %}

mais, hélas, l'objet réel context est [...]

@westurner , alors ça marche? Je ne peux pas le vérifier pour le moment, mais il me semble que {{ locals() }} devrait échouer s'il contient des octets non convertibles.

• json.dumps(locals()) ne fonctionnera pas sans un JSONEncoder personnalisé (avec par exemple repr() pour [code objects,])
• peut-être pprint.pformat(locals()) ? (ce serait une fonction intégrée pratique)

• ... autoescape=True empêcherait alors XSS

Ce serait une aubaine à avoir lors de l'extension des modèles d'une application tierce. J'utilise actuellement le hiéroglyphe pour créer des diaporamas, qui s'appuie sur le sphinx, et donc sur Jinja2.

J'ai étendu le thème hiéroglyphe par défaut, et ce que j'aimerais savoir, c'est si le modèle contient une variable qui me dit si je suis sur une diapositive ou non. Peut-être que la variable est là, peut-être qu'elle ne l'est pas. Je suis donc actuellement en train de fouiller dans le code source des hiéroglyphes pour trouver ce dont j'ai besoin.

Pouvoir simplement vider toutes les variables disponibles directement à partir du modèle (c'est-à-dire sans modifier le code Python) rendrait cela beaucoup plus rapide et plus facile. Donc, disons que pouvoir faire quelque chose comme ça serait bien :

{% extends "!layout.html %}

{# ... or any other sensible name #}
{% dump_variables() %}

{% block body %}
Hello World!
super()
Goodbye World
{% endblock %}

De cette façon, je pouvais introspecter tout hiéroglyphe qui m'était proposé tout en développant le nouveau thème.

J'ai créé une extension à cet effet, elle peut être trouvée à https://github.com/niwinz/django-jinja/files/1607805/jinja_extensions.py.txt

@ShaheedHaque des écrans ?

Si vous ouvrez le fichier, les commentaires contiennent un exemple de la sortie. Si
besoin, je peux fournir une capture d'écran réelle quand je rentre à la maison ce soir...

Le 6 janvier 2018 à 02h23, "anatoly techtonik" [email protected] a écrit :

@ShaheedHaque https://github.com/shaheedhaque des écrans ?

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pallets/jinja/issues/174#issuecomment-355716273 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AEp7KdBBslHJPIGp5VliuF74bxSZTk-wks5tHtkEgaJpZM4AXefd
.

L'écran @ShaheedHaque serait vraiment agréable à comparer avec la sortie Smarty du premier message.

Comme demandé. Vous verrez que le contenu est organisé (et trié) par variables de contexte, filtres et tests. Aussi, voici une vue agrandie sur un écran avec quelques variables de contexte plus "intéressantes". Voyez comment la limite de profondeur = 3 est suffisante pour montrer un peu de détail, sans encourir la possibilité d'une sortie trop imbriquée puisque, je crois, la chose la plus demandée est de savoir exactement quelles variables de contexte (de niveau supérieur) sont présentes et non le profondeur totale de toute structure :

Vous verrez également probablement qu'il est trivial de modifier/étendre les détails de ce qui est affiché (ou ce le sera, pour quelqu'un qui sait comment fonctionne l'analyseur... Je ne suis pas dans ce cercle béni :-)).

Semble utile. Alors pourquoi ne pas remplir un PR?

Je serais heureux de le faire étant donné quelques conseils sur l'endroit où le nouveau code devrait vivre dans la base de code ninja (je ne suis pas familier avec ce projet).

Moi non plus, mais https://github.com/pallets/jinja/blob/master/jinja2/ext.py semble être un bon début.

Voir PR #798.

Sera disponible en tant que nouvelle extension dans la version 2.11.

Merci!

Les documents d'extension de débogage doivent avertir les utilisateurs des
divulgation d'informations sensibles
via la balise {% debug %} , et comment déterminer si l'extension
est activé (afin qu'un analyseur statique puisse identifier que quelqu'un a oublié de
supprimer {% debug .* %} avant la publication.

983

Le vendredi 4 octobre 2019, David Lord [email protected] a écrit :

Fermé #174.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.