Ich müsste es überprüfen, aber ich denke, das sollte funktionieren:

<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 von 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

Zum Debuggen kann z. B. pyramid_debugtoolbar den Vorlagenkontext anzeigen, wenn die Ansichtsfunktion - meiner Meinung nach entsprechend abstrahiert - nur ein Kontextobjekt zurückgibt (z. B. dict, OrderedDict).

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

Anwendungsfall

Mein Anwendungsfall hier besteht darin, ein paar Argumente von einem CLI-Dienstprogramm an eine jinja2-Vorlage zu übergeben (wo ich Standardwerte innerhalb der Vorlage definieren möchte (z. B. für Dockerfiles (ausgerechnet ohne autoescape ))

Was ich gerne tun würde, ist

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

aber leider ist das eigentliche context Objekt [...]

@westturner , also funktioniert es? Ich kann es gerade nicht überprüfen, aber es scheint mir, dass {{ locals() }} fehlschlagen sollte, wenn es nicht konvertierbare Bytes enthält.

• json.dumps(locals()) funktioniert nicht ohne einen benutzerdefinierten JSONEncoder (mit z. B. repr() für [Code-Objekte,])
• vielleicht pprint.pformat(locals()) ? (Dies wäre ein praktischer Einbau)

• ... autoescape=True würde dann XSS verhindern

Dies wäre ein Segen, wenn Sie Vorlagen einer Drittanbieter-App erweitern. Ich verwende derzeit Hieroglyphe , um Diashows zu erstellen, die auf Sphinx und damit Jinja2 aufbauen.

Ich habe das Standard-Hieroglyphenthema erweitert und möchte herausfinden, ob die Vorlage eine Variable enthält, die mir sagt, ob ich mich auf einer Folie befinde oder nicht. Vielleicht ist die Variable da, vielleicht nicht. Also stöbere ich gerade im Hieroglyphen-Quellcode, um zu finden, was ich brauche.

In der Lage zu sein, alle verfügbaren Variablen einfach direkt aus der Vorlage heraus auszugeben (d. h. ohne den Python-Code zu ändern), würde dies so viel schneller und einfacher machen. Nehmen wir also an, es wäre schön, so etwas tun zu können:

{% extends "!layout.html %}

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

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

Auf diese Weise konnte ich bei der Entwicklung des neuen Themas alles prüfen, was mir eine Hieroglyphe bietet.

Zu diesem Zweck habe ich eine Erweiterung erstellt, die unter https://github.com/niwinz/django-jinja/files/1607805/jinja_extensions.py.txt zu finden ist

@ShaheedHaque irgendwelche Bildschirme?

Wenn Sie die Datei öffnen, enthalten die Kommentare ein Beispiel für die Ausgabe. Wenn
benötigt, kann ich einen aktuellen Screenshot liefern, wenn ich heute Abend nach Hause komme ...

Am 6. Januar 2018 um 02:23 Uhr schrieb "anatoly techtonik" [email protected] :

@ShaheedHaque https://github.com/shaheedhaque irgendwelche Bildschirme?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pallets/jinja/issues/174#issuecomment-355716273 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AEp7KdBBslHJPIGp5VliuF74bxSZTk-wks5tHtkEgaJpZM4AXefd
.

Der @ShaheedHaque -Bildschirm wäre wirklich schön, um ihn mit der Smarty-Ausgabe aus dem ersten Beitrag zu vergleichen.

Wie gewünscht. Sie werden sehen, dass die Inhalte nach Kontextvariablen, Filtern und Tests organisiert (und sortiert) sind. Außerdem ist hier eine vergrößerte Ansicht auf einem Bildschirm mit einigen weiteren "interessanten" Kontextvariablen. Sehen Sie, wie die Begrenzung auf Tiefe = 3 ausreicht, um ein wenig Detail zu zeigen, ohne die Möglichkeit einer übermäßig verschachtelten Ausgabe zu verursachen, da meiner Meinung nach am meisten nachgefragt wird, genau zu wissen, welche Kontextvariablen (der obersten Ebene) vorhanden sind und nicht die volle Tiefe beliebiger Strukturen:

Sie werden wahrscheinlich auch sehen, dass es trivial ist, die Details dessen, was gezeigt wird, zu ändern/erweitern (oder wird es sein, für jemanden, der weiß, wie der Parser funktioniert ... Ich bin nicht in diesem gesegneten Kreis :-)).

Sieht nützlich aus. Warum also nicht eine PR füllen?

Ich würde das gerne tun, wenn ich eine Anleitung gebe, wo in der Ninja-Codebasis der neue Code leben sollte (ich bin mit diesem Projekt nicht vertraut).

Ich auch nicht, aber https://github.com/pallets/jinja/blob/master/jinja2/ext.py scheint ein guter Anfang zu sein.

Siehe PR-Nr. 798.

Wird als neue Erweiterung in 2.11 verfügbar sein.

Danke!

Die Dokumentation zur Debug-Erweiterung sollte Benutzer vor unbeabsichtigten Fehlern warnen
Offenlegung sensibler Informationen
durch das Tag {% debug %} und wie man feststellt, ob die Erweiterung
aktiviert ist (damit ein statischer Analysator erkennen kann, dass jemand vergessen hat
entfernen Sie {% debug .* %} vor der Veröffentlichung.

983

Am Freitag, den 4. Oktober 2019, schrieb David Lord [email protected] :

Geschlossen Nr. 174.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.