#21881 closed Bug (fixed)
Clarify that `{% ssi ... parsed %}` has the same limitations as `{% include %}`
Reported by: | Viktor | Owned by: | mamun |
---|---|---|---|
Component: | Documentation | Version: | 1.5 |
Severity: | Normal | Keywords: | ssi block |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
Please, see https://github.com/pulilab/django-ssi-tag-block for a simple test app that demonstrates this bug.
What would you expect to be rendered when the page.html
file gets rendered with the following templates?
page.html
{% extends "base.html" %} {% block content %} Everything fine. The content block was overwritten! {% endblock %}
base.html
{# included_template == ssi.html #} {% ssi included_template parsed %}
ssi.html
<!DOCTYPE html> <html> <head> <title></title> </head> <body> {% block content %} This is the original content block. You should never see me. {% endblock %} </body> </html>
My expectation would be to see the text "Everything fine. The content block was overwritten!". But this did not happen.
Attachments (1)
Change History (8)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Reading the docs for the {% ssi %}
tag tells just the opposite [1]:
If the optional “parsed” parameter is given, the contents of the included file are evaluated as template code, within the current context
This is the reason why I was using ssi
instead of include
.
[1] https://docs.djangoproject.com/en/1.5/ref/templates/builtins/#std:templatetag-ssi
comment:3 by , 11 years ago
Component: | Template system → Documentation |
---|---|
Easy pickings: | set |
Summary: | block tags behavior with {% ssi %} is broken → Clarify that `{% ssi ... parsed %}` has the same limitations as `{% include %}` |
Triage Stage: | Unreviewed → Accepted |
That sentence is not completely clear, I'll admit.
The fact is that {% ssi %}
has the same limitations as {% include %}
: even when you use the parsed
option, included templates are rendered separately, so you can't for example alter the context or define blocks.
This is what the note in {% include %}
tries to convey.
I'm going to mark this ticket as accepted
(and change its description) but as I see, it's a documentation issue.
We should make it more clear that the parsed
option has the same limitation as {% include %}
.
What do you think?
comment:4 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
by , 11 years ago
Attachment: | django_templates_ssi_rendering_note.patch added |
---|
comment:5 by , 11 years ago
Has patch: | set |
---|
I've added a small note to the {% ssi %} tag documentation to clarify its behaviour.
comment:6 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Hi,
I don't think that's a bug but rather a limitation of the current system. It's documented as a note for the
{% include %}
tag [1]:Maybe that should be made clearer in the paragraph for
{% ssi %}
too.What do you think?
[1] https://docs.djangoproject.com/en/1.6/ref/templates/builtins/#include