Hi Russell,
I'd define
> {% for templ in template_list %}
> {% include templ %}
> {% endfor %}
as a special case, for which special command or pattern should exist.
Should it be
{% for templ in template_list %}
{% try-include template %}
{% endfor %}
or the opposite to be called
{% require template %} instead of include,
or maybe this whole pattern should be written as
{% include-first templ %}
But in most cases {% include %} is used as "require", so in my
opinion it should raise errors!
I'd also consider a require-once pattern to fix common widget chrome
problems (i.e. different parts of the page might include jquery in
headers).
On Thu, Sep 2, 2010 at 1:00 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> 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.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
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.
