On Thu, Sep 2, 2010 at 1:42 PM, burc...@gmail.com <burc...@gmail.com> wrote:
> Hi George,
>
> I believe this is a bug since any other errors in admin (not related
> to inlines) don't pass silently.
>
> Silencing errors should always be documented, especially if error is
> silenced when DEBUG is turned on.
>
> So it's either documentation or implementation bug.
IMHO, it's a documentation issue, not a bug. It all comes down to how
you interpret the operation of the {% include %} tag.
In one interpretation, you can look at at the {% include %} as a major
structural node in the template, whose role is to substitute the
contents of a subtemplate. In this case, the {% include %} doesn't
actually exist in the final template; it's just a placeholder that
gets expanded as part of the original parsing process. In this
interpretation, any syntax error in the include node would be surfaced
as a syntax error in the main parent template doing the including.
Alternatively, you can look at {% include %} as being just like any
other tag. It exists as a normal template node, and the parsed parent
template contains a node that represents the {% include %}. At
runtime, the {% include %} tag substitutes it's content; and if that
raises an error, then the rendering process swallows that error.
The second interpretation what actually happens in implementation. {%
includes %} are actual nodes in the parsed template tree. The reason
for this is that the name of the template that is rendered is actually
a variable - For example, consider the following:
{% for templ in template_list %}
{% include templ %}
{% endfor %}
The included template isn't actually loaded and resolved until time of
render. As a result, we aren't in a position to raise a
TemplateSyntaxError when we parse the original document tree. We only
parse the included template when we render the parent template with a
specific context.
For the record, this distinction is also why {% cycle %} tags don't
persist over iterated {% include %}s -- each {% include %} is an
independent rendering context, so a cycle in one include doesn't
affect subsequent iterations.
So - this is a documentation issue. However, it's a pretty subtle
point, so it's not easy to explain. If anyone wants to take a swing at
trying to explain the issue, it would certainly be a valuable
contribution to the docs, and would possibly reduce the number of
invalid bug reports that are logged against the behavior of the
include tag.
That said: if anyone has any bright ideas on how to improve error
handling when rendering templates, we're open to suggestions. However,
my original point -- that runtime template errors are considered
unacceptable -- still stands, and any suggestion needs to honor that.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
