On Thu, Sep 2, 2010 at 5:04 PM, burc...@gmail.com <burc...@gmail.com> wrote:
> 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.

First off, I'm not about to add a second template tag for including
subtemplates. One is more than sufficient.

Secondly, I still don't see how what you're describing is possible.
The name of the template to be included is not determined until the
template is *rendered*. This is a completely to when the template is
*parsed*, and it is the *parsing* process that generates
TemplateSyntaxErrors. If we can't work out which subtemplate is to be
used until rendering, we can't raise a syntax error when the parent
template is parsed.

> 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.

At this point, you're going to need to show me a patch. I can't see
how what you're describing is possible without violating the stateless
nature of the parsed template tree and/or doing some sort of template
pre-rendering.

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.

Reply via email to