Russell,
Sorry, we didn't understand each other,
You're talking about additional problems for templates with variable names.
However main point that George made was that he wanted template
rendering to break when including templates fails, no matter if that
was in the parse time or rendering time.
To address your "original point -- that runtime template errors are
considered unacceptable" I suggested that we have 2 different template
tags instead of include, one that will break, another one that will
not, because me and George wanted to have not the current version of
include tag but one that breaks on errors.
Implementation could look like the following: wrapper in the render()
part of include node, that uses some internal "current template"
variable. Another variable in the parser for this purpose.
P.S. This improvement is also related to my syntax coloring feature,
since I wanted to improve template errors display as well.
On Thu, Sep 2, 2010 at 1:41 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Thu, Sep 2, 2010 at 2:30 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>> 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).
>
> Either I'm completely missing the point you're trying to make, or
> you've completely missed the point I was making.
>
> Template rendering is a two step process:
> 1. Parse the template
> 2. Render the template.
>
> The point I was trying to make is that at step 1, we *can't* know the
> name of the subtemplate used in an {% include %}. This isn't a matter
> for negotiation or something we are in a position to design -- it's
> simply the way that the tag is implemented.
>
> I don't see how changing the name of the include tag to "require" or
> "try-include" changes anything, or how an alternate tag with those
> names would behave differently.
>
> 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.
