New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using {{ caller() }} within {% call %} fails #371
Comments
I'm able to reproduce this with this small example: {% macro a() %}
start of a
{% call b() %}
{{ caller() }}
{% endcall %}
end of a
{% endmacro %}
{% macro b() %}
start of b
{{ caller() }}
end of b
{% endmacro %}
{% call b() %}
inside b only
{% endcall %}
{#
{% call a() %}
inside a
{% endcall %}
#} This works fine as-is, when the last block is uncommented, we get the following traceback: Traceback (most recent call last):
...
File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 894, in render
return self.environment.handle_exception(exc_info, True)
File "templates/test.j2", line 19, in top-level template code
{% call a() %}
File "templates/test.j2", line 3, in template
{% call b() %}
File "templates/test.j2", line 11, in template
{{ caller() }}
File "templates/test.j2", line 4, in template
{{ caller() }}
jinja2.exceptions.UndefinedError: No caller defined |
Small note about the workaround: The new feature of 2.8 is not needed as this is also working fine: {% macro a() %}
start of a
{% set content=caller() %}
{% call b() %}
{{ content }}
{% endcall %}
end of a
{% endmacro %}
{% macro b() %}
start of b
{{ caller() }}
end of b
{% endmacro %}
{% call b() %}
inside b only
{% endcall %}
{% call a() %}
inside a
{% endcall %} |
This is sort of intentional as it always scopes to the closest macro. Closing as wontfix. |
FYI, Anyway, this might be worth a FAQ entry. I remember a colleague having the exact same problem some time ago until we figured out that |
Yeah, we might want to put that into the docs. |
The actual template where I encountered the issue first was more boilerplate-ish, but I this one describes the problem in a more intuitive way.
Suppose we have the following template:
along with a higher level template that tries to
{% call %}
it for some specific case:Intuitively, doing
{% call _div(...) %} <b>foo</b> {% endcall %}
should pass<b>foo</b>
to the_tag
macro, which would then render it (verbatim, thanks to autoescape). But the actual result isUndefinedError: No caller defined
on the{{ caller() }}
line inside_div
. It would seem that the scope ofcaller
does not extend into the{% call %}
block, thereby preventing chained calls such as the one depicted above.There is an ugly workaround that uses the new block assignment feature from 2.8:
but, of course, the original version would be much more preferable.
The text was updated successfully, but these errors were encountered: