On Sep 30, 10:00 am, Armin Ronacher <[EMAIL PROTECTED]>
wrote:
> Hi,
>
>
>
> Eric wrote:
> > We recently started upgrading from jinja to jinja2 and ran into a
> > rather large road block. Basically, in jinja2 templates rendered via
> > {% include %} do not have access to variables defined in the parent
> > template.
>
> > So the following would print nothing:
>
> > # parent template
> > {% for value in values %}
> > {% include "test_include" %}
> > {% endfor %}
>
> > # test include
> > {{ value }}
>
> > Was this change in behavior intended when writing jinja2?
>
> Yes. That's an intentional change. Included templates (if evaluated with
> the context which is the default) are only passed the actual context. The
> context are the variables passed to the initial render function. Instead
> of using `{% include %}` in hat way you should use macros instead:
>
> macros.html:
>
> {% macro render_value(value) %}
> <div>...{{ value }}...</div>
> {% endmacro %}
>
> template.html
>
> {% from "macros.html" import render_value %}
> {% for value in values %}
> {{ render_value(value) }}
> {% endfor %}
>
> The reason why we do not support the previous system any longer is that it
> turned out that implicit variables passing is causing templates that are
> hard to understand for new template designers (which variables are coming
> from where, which are available and which are only there because of a
> specific template situation).
>
> Macros on the other hand require you to explicitly name the variables that
> are passed to the macro, thus easier to understand a while later.
>
> There are currently no intentions to change this, but I do agree that
> porting templates over from Jinja1 or Django could make this more complex
> that it would have to be.
>
> Regards,
> Armin
I agree completely with your reasoning. However, after thinking about
this for a little bit, I wonder if this behavior would be more
confusing to designers coming from other template languages. Django
and jinja1 being the obvious ones, but also ones from other languages:
java: jsp, velocity
php: php, smarty
I honestly can't think of a templating engine that I've used that
doesn't give the include access to the same variables that any other
line of code at that location has access to.
Perhaps the new jinja2 behavior can be an optional one. Either via
some environment setting or declaratively via the include statement.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pocoo-libs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pocoo-libs?hl=en
-~----------~----~----~----~------~----~------~--~---
