On Thu, Sep 2, 2010 at 8:47 PM, burc...@gmail.com wrote:
> On Thu, Sep 2, 2010 at 6:27 PM, Russell Keith-Magee
> wrote:
>> On Thu, Sep 2, 2010 at 5:04 PM, burc...@gmail.com wrote:
>>> Russell,
>>>
>>> Sorry, we didn't understand each other,
>>>
>>> You're talking about additional problems for te
On Thu, Sep 2, 2010 at 6:27 PM, Russell Keith-Magee
wrote:
> On Thu, Sep 2, 2010 at 5:04 PM, 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 ma
On Thu, Sep 2, 2010 at 7:40 PM, George Karpenkov
wrote:
> 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
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?
A
On Thu, Sep 2, 2010 at 5:04 PM, 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 te
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 tim
On Thu, Sep 2, 2010 at 2:30 PM, 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 %}
> {% tr
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
On Thu, Sep 2, 2010 at 1:42 PM, burc...@gmail.com wrote:
> Hi George,
>
> I believe this is a bug since any other errors in admin (not related
> to inlines) don't pass silently.
>
> Silencing errors should always be documented, especially if error is
> silenced when DEBUG is turned on.
>
> So it's
Hi George,
I believe this is a bug since any other errors in admin (not related
to inlines) don't pass silently.
Silencing errors should always be documented, especially if error is
silenced when DEBUG is turned on.
So it's either documentation or implementation bug.
By the way, does it show 50
Dear Russell,
I don't quite understand how an error in the admin template is
different from the error in the inline template -- why one gets
silenced and another one doesn't?
Well if I am the only person who got repeatedly hit by that
particular issue, then I guess I'll have to deal with that.
On Wed, Sep 1, 2010 at 2:03 PM, George Karpenkov
wrote:
> Steps to reproduce:
> 1) Specify a custom admin class (say A) which mentions a custom inline
> with a custom template, say "a.html"
> 2) Write anything to "a.html" which will raise TemplateSyntaxError -
> ie "{% extends "a.html" %}
> 3) Obs
Steps to reproduce:
1) Specify a custom admin class (say A) which mentions a custom inline
with a custom template, say "a.html"
2) Write anything to "a.html" which will raise TemplateSyntaxError -
ie "{% extends "a.html" %}
3) Observe the change_form for A. Note that you do not see any errors,
but
13 matches
Mail list logo
