Dear Russ, I still don't quite get why "runtime template errors are unacceptable". My understanding is that if user has DEBUG=True, and TEMPLATE_DEBUG=True, then clearly (at least to me) the user does want to see all of the errors. DEBUG flags should be off in the production environment, right?
Alternatively, the simplest solution that comes to my mind is to have a third flag CAN_I_REALLY_HAVE_TEMPLATE_DEBUG_PLZ_K_THX (I am not good at making up naming conventions) and if that one is set to True then do not silence _any_ errors at all during template rendering. George On Sep 2, 9:27 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > 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.
