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.