On Thu, Sep 2, 2010 at 8:47 PM, burc...@gmail.com <burc...@gmail.com> wrote:
> On Thu, Sep 2, 2010 at 6: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.
> Russell,
>
> Sorry. One more try.
>
> We don't need a error to be raised exactly on parsing stage, it's
> enough if parse error is raised on rendering.
>
> Do you mean we can't raise a syntax error when the included template
> is *rendered*?

You managed to peak my curiosity, so I took a quick look at the
implementation of {% include %}. I'm now completely confused as to the
problem you're having.

The current Django 1.2 implementation of the {% include %} tag *does*
raise a TemplateSyntaxError during rendering if the subtemplate has an
error -- but only if TEMPLATE_DEBUG=True. If you have a syntax error
in an included subtemplate, and you're in TEMPLATE_DEBUG mode, you
*should* be getting template syntax errors for an invalid included
template.

My comments so far have all been based on trying to explain the
behavior George originally described in terms of the broader
philosophy behind Django's template language, but I didn't actually
verify that problem as described. So - I went back to George's
original report and tried to reproduce the problem. I've added a
custom template to an inline ModelAdmin class. If I put a syntax error
in that file (I tried both an {%extends%} of a non-existing template,
and a missing {% endfor %} tag), I get a TemplateSyntaxError.

However, if I set TEMPLATE_DEBUG=False, I get the behavior George
described -- non-rendering of the inline, rather than the error.

So - what exactly is the problem here? Is this just a case of not
having DEBUG turned on?

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