Rethinking silent failures in templates

[Simon Willison-2]

Hi all,

Some time in late 2003, Adrian and I decided that errors in templates
were best handled silently - the idea was that it would prevent
untrained template editors from being able to 500-error a site with a
typo.

Is it too late to reconsider this decision, four and a half years
later? I can't think of a single time this feature has helped me, and
plenty of examples of times that it has tripped me up.

Today's example: a <form action=""> tag that shouldn't have been
blank. The code looked like this:

<form action="{% url something-with-a-typo %}">

If you look at Django's URL tag implementation, you can see why:

http://code.djangoproject.com/browser/django/trunk/django/template/defaulttags.py?rev=6996#L364

The code catches the NoReverseMatch exception and silences it,
outputting an empty string instead.

Silent errors are bad. If we were to remove them, how much of a
negative impact would it have on the existing user base?

Cheers,

Simon



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[George Vilches]

On May 14, 2008, at 9:58 AM, Simon Willison wrote:
> Silent errors are bad. If we were to remove them, how much of a
> negative impact would it have on the existing user base?

I suspect that a lot of people actually rely on this behavior, and it  
would be devastating to them.  What I've personally hoped for (besides  
a pony) was a bit of both: a development mode where I could turn on  
template errors and have them trickle to me, and then a setting that  
allows me to turn that off in production.  That's the best of both  
worlds, and I'm sure makes the template code ridiculously more  
complicated so it probably won't happen.  But I'd still like it.

gav

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Simon Willison-2]

On May 14, 3:02 pm, George Vilches <[hidden email]> wrote:
> On May 14, 2008, at 9:58 AM, Simon Willison wrote:
> > Silent errors are bad. If we were to remove them, how much of a
> > negative impact would it have on the existing user base?
>
> I suspect that a lot of people actually rely on this behavior, and it
> would be devastating to them.

Thinking about it some more you're right - I'm sure there are lots of
cases where people are relying on things like the following:

{{ article.something.title }} - outputs text if article is there,
fails silently otherwise

Which leaves us in a tricky situation. A global settings.py variable
for "throw errors on missing template variables" is a bad idea as it
kills application portability (the PHP magic_quotes problem again - if
your application expects that setting off and mine expects it on I
can't import your app in to my environment). There might be something
we can do with warnings, but it could still end up pretty messy. Needs
more thought.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Deryck Hodge]

On Wed, May 14, 2008 at 9:07 AM, Simon Willison <[hidden email]> wrote:
> Which leaves us in a tricky situation. A global settings.py variable
> for "throw errors on missing template variables" is a bad idea as it
> kills application portability (the PHP magic_quotes problem again - if
> your application expects that setting off and mine expects it on I
> can't import your app in to my environment). There might be something
> we can do with warnings, but it could still end up pretty messy. Needs
> more thought.

Hi, Simon.

Could you not just tie it to the DEBUG setting?  That is the worry,
after all, right? -- that a production site will 500.  Development it
doesn't matter, and generally, people use DEBUG to distinguish the
two.

Just a quick thought...  I haven't looked at the code to know the
implications of using DEBUG as the flag.

Cheers,
deryck


--
Deryck Hodge
http://www.devurandom.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Marty Alchin-2]

On Wed, May 14, 2008 at 10:07 AM, Simon Willison
<[hidden email]> wrote:
>> I suspect that a lot of people actually rely on this behavior, and it
>> would be devastating to them.
>
> Thinking about it some more you're right - I'm sure there are lots of
> cases where people are relying on things like the following:
>
> {{ article.something.title }} - outputs text if article is there,
> fails silently otherwise

I'm not expert on the history of this or anything, but I always
thought this example was the basis for silent errors. That makes me
wonder, then, if there's some other kind of separation we can have.
Perhaps variable lookups continue to fail silently, regardless of
environment, while actual {% ... %} tags raise errors by default.

Of course, there's still something to be said for using DEBUG to show
errors in development, while not in production, and individual tags
would obviously be able to suppress their own errors if they choose
to, but I think it might work.

And at the risk of supplying too many possibilities for one email, the
magic_quotes problem could be avoided similarly to autoescaping.
Essentially, provide an extra argument to all the template rendering
functions, with a default based on the DEBUG (or other) setting.
Something like def render(self, context, silent_errors=not
settings.DEBUG). Then, individual apps can specify their behavior
explicitly if they need to, while relying on the setting if they
don't.

I'm probably way off-base on these ideas, though, because it would
likely lead to a lot of "hey, why is this template erroring out, while
this other one isn't?" I dunno. This email was probably too
stream-of-consciousness to be of any use. But there it is.

-Gul

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Waylan Limberg]

On Wed, May 14, 2008 at 10:10 AM, Deryck Hodge <[hidden email]> wrote:

>
>  On Wed, May 14, 2008 at 9:07 AM, Simon Willison <[hidden email]> wrote:
>  > Which leaves us in a tricky situation. A global settings.py variable
>  > for "throw errors on missing template variables" is a bad idea as it
>  > kills application portability (the PHP magic_quotes problem again - if
>  > your application expects that setting off and mine expects it on I
>  > can't import your app in to my environment). There might be something
>  > we can do with warnings, but it could still end up pretty messy. Needs
>  > more thought.
>
>  Hi, Simon.
>
>  Could you not just tie it to the DEBUG setting?  That is the worry,
>  after all, right? -- that a production site will 500.  Development it
>  doesn't matter, and generally, people use DEBUG to distinguish the
>  two.
>

Well, say I have a template in which {{ article.something.title }} is
expected to fail silently in some cases. Suppose I also happen to have
another bug later in that template. In development (DEBUG mode on), I
don't want {{ article.something.title }} to generate an error, but I
do want that other later (as yet unknown) problem to give me django's
handy error page. If it always trips up on {{ article.something.title
}}, I'll never get to that other error which happens later in the
processing until I move to production and no longer get nice error
pages to help me find it.

Therefore, I think we need a way to distinguish between what parts of
the template should fail silently, and what parts should not. Perhaps
some sort of filter or tag or combination thereof. Not unlike
autoescaping  -- fail by default and fail silently only were
explicitly set. Of course, this opens up a whole can-of-worms
regarding whether one tag affects the whole template, inherited
templates, a block in the template, or just a single variable lookup
or some combination of them all. Ug - don't want to go through that
again.

Hmm, before I posted this, I see that Marty has similar thoughts.
Maybe it's not so crazy after all.



--
----
Waylan Limberg
[hidden email]

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Kenneth Arnold-2]

I made some comments on bug #5140 a while back, before I realized that
bug reports weren't a great place to discuss important things. That
bug bit me quite enough back in the early days of my project.

I'd definitely want to know if any url templatetag failed. And
probably any variable lookup also; if I didn't put |default:"" after
it, I probably wanted that value.

How's this for a prototype idea:
1. Production sites (DEBUG=False) keep the current behavior. Period.
The rest of this only applies if TEMPLATE_DEBUG is on.
2. If the docs specify specific failure behavior (like for first,
etc.), the docs win.
3. Tags and filters that specify the syntax of their output (e.g., the
output of a url tag should be a URL) fail if they can't provide that
output.
4. Other tags and filters, like include, ssi, and truncatewords (from
a quick scan) that perform some function that could fail, should mark
that failure very clearly in the output. (Those two currently do, but
the error string is easy to miss if buried in a mess of other code.)
5. Variable lookups, and everything else, never cause render() to
fail, but insert an easy-to-catch and easy-to-bypass error string in
the output.

So what is that error string? First of all, it should be something for
which bool(x) is False, so that defaulting, etc. all work as expected.
But if it does make it to the output, I see two choices:

a. Make its presence very well known. All caps text, ASCII art, etc.
b. Keep it on the down-low. HTML comment, for example.

My preference is for the first, partially because an HTML comment
might not be appropriate in the context.

But either way, the error string should have some known pattern that a
middleware could look for and report an exception for.

It could also log a message in its __str__ method.

Thoughts?
-Ken


On May 14, 9:58 am, Simon Willison <[hidden email]> wrote:

> Hi all,
>
> Some time in late 2003, Adrian and I decided that errors in templates
> were best handled silently - the idea was that it would prevent
> untrained template editors from being able to 500-error a site with a
> typo.
>
> Is it too late to reconsider this decision, four and a half years
> later? I can't think of a single time this feature has helped me, and
> plenty of examples of times that it has tripped me up.
>
> Today's example: a <form action=""> tag that shouldn't have been
> blank. The code looked like this:
>
> <form action="{% url something-with-a-typo %}">
>
> If you look at Django's URL tag implementation, you can see why:
>
> http://code.djangoproject.com/browser/django/trunk/django/template/de...
>
> The code catches the NoReverseMatch exception and silences it,
> outputting an empty string instead.
>
> Silent errors are bad. If we were to remove them, how much of a
> negative impact would it have on the existing user base?
>
> Cheers,
>
> Simon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Ivan Sagalaev]

Simon Willison wrote:
> {{ article.something.title }} - outputs text if article is there,
> fails silently otherwise
>
> Which leaves us in a tricky situation. A global settings.py variable
> for "throw errors on missing template variables" is a bad idea as it
> kills application portability

It doesn't if we clearly document that silent beahviour is for
production and breakage is for debug. This setting won't travel with
application code but will be right alongside DEBUG in settings. Actually
there is such setting: TEMPLATE_DEBUG. We can just add this braking
effect to it. I believe it's pretty intuitive.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[David Zhou]

I like the filter idea -- maybe something like 'required'  It could be  
similar to marking things as safe for the autoescaping.

Default behavior should be silent failures, and authors can explicitly  
set variable calls to fail visibly.

So with Simon's original example, the template author would realize  
that this is something that should not be blank, and do:

<form action="{% url something-with-a-typo|required %}">

But then with normal variable calls, would fail silently as usual:

{{ article.something.title }}

On May 14, 2008, at 10:43 AM, Waylan Limberg wrote:

>
> On Wed, May 14, 2008 at 10:10 AM, Deryck Hodge <[hidden email]>  
> wrote:
>>
>> On Wed, May 14, 2008 at 9:07 AM, Simon Willison <[hidden email]
>> > wrote:
>>> Which leaves us in a tricky situation. A global settings.py variable
>>> for "throw errors on missing template variables" is a bad idea as it
>>> kills application portability (the PHP magic_quotes problem again  
>>> - if
>>> your application expects that setting off and mine expects it on I
>>> can't import your app in to my environment). There might be  
>>> something
>>> we can do with warnings, but it could still end up pretty messy.  
>>> Needs
>>> more thought.
>>
>> Hi, Simon.
>>
>> Could you not just tie it to the DEBUG setting?  That is the worry,
>> after all, right? -- that a production site will 500.  Development it
>> doesn't matter, and generally, people use DEBUG to distinguish the
>> two.
>>
> Well, say I have a template in which {{ article.something.title }} is
> expected to fail silently in some cases. Suppose I also happen to have
> another bug later in that template. In development (DEBUG mode on), I
> don't want {{ article.something.title }} to generate an error, but I
> do want that other later (as yet unknown) problem to give me django's
> handy error page. If it always trips up on {{ article.something.title
> }}, I'll never get to that other error which happens later in the
> processing until I move to production and no longer get nice error
> pages to help me find it.
>
> Therefore, I think we need a way to distinguish between what parts of
> the template should fail silently, and what parts should not. Perhaps
> some sort of filter or tag or combination thereof. Not unlike
> autoescaping  -- fail by default and fail silently only were
> explicitly set. Of course, this opens up a whole can-of-worms
> regarding whether one tag affects the whole template, inherited
> templates, a block in the template, or just a single variable lookup
> or some combination of them all. Ug - don't want to go through that
> again.
>
> Hmm, before I posted this, I see that Marty has similar thoughts.
> Maybe it's not so crazy after all.
>
>
>
> --
> ----
> Waylan Limberg
> [hidden email]
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Nicola Larosa (tekNico)-2]

Simon Willison wrote:
> Silent errors are bad. If we were to remove them, how much of a
> negative impact would it have on the existing user base?

+1 from me.

I always set TEMPLATE_DEBUG to True and TEMPLATE_STRING_IF_INVALID to
something that stands out, during development.

--
Nicola Larosa - http://www.tekNico.net/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[J. Cliff Dyer-2]

On Wed, 2008-05-14 at 19:00 +0400, Ivan Sagalaev wrote:

> Simon Willison wrote:
> > {{ article.something.title }} - outputs text if article is there,
> > fails silently otherwise
> >
> > Which leaves us in a tricky situation. A global settings.py variable
> > for "throw errors on missing template variables" is a bad idea as it
> > kills application portability
>
> It doesn't if we clearly document that silent beahviour is for
> production and breakage is for debug. This setting won't travel with
> application code but will be right alongside DEBUG in settings. Actually
> there is such setting: TEMPLATE_DEBUG. We can just add this braking
> effect to it. I believe it's pretty intuitive.
>

-1

I'm a fairly strong -1 on adding this across the board to debug
behavior, especially if it causes the template not to render.  If having
a variable missing is expected behavior in some cases, and should result
in nothing being inserted,  (and it frequently is for me) then causing
the page to break will make actual debugging impossible.

On the other hand, I'm +1 on the idea of having a filter to mark a
variable as required.

Cheers,
Cliff



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[George Vilches]

On May 14, 2008, at 12:29 PM, J. Cliff Dyer wrote:

>
> On Wed, 2008-05-14 at 19:00 +0400, Ivan Sagalaev wrote:
>> Simon Willison wrote:
>>> {{ article.something.title }} - outputs text if article is there,
>>> fails silently otherwise
>>>
>>> Which leaves us in a tricky situation. A global settings.py variable
>>> for "throw errors on missing template variables" is a bad idea as it
>>> kills application portability
>>
>> It doesn't if we clearly document that silent beahviour is for
>> production and breakage is for debug. This setting won't travel with
>> application code but will be right alongside DEBUG in settings.  
>> Actually
>> there is such setting: TEMPLATE_DEBUG. We can just add this braking
>> effect to it. I believe it's pretty intuitive.
>>
>
> -1
>
> I'm a fairly strong -1 on adding this across the board to debug
> behavior, especially if it causes the template not to render.  If  
> having
> a variable missing is expected behavior in some cases, and should  
> result
> in nothing being inserted,  (and it frequently is for me) then causing
> the page to break will make actual debugging impossible.
>
> On the other hand, I'm +1 on the idea of having a filter to mark a
> variable as required.

I mirror these sentiments exactly, with one exception.  I don't think  
filters are the right way to do this, for two reasons:

1) It's very limiting.  There's lots of places that filters can't be  
applied cleanly that would still make sense to have some subset of  
behavior like this
2) It seems impossible.  How can you have a filter that checks whether  
the scope of some variable existed in a previous call, since the  
filter only runs on the *output* of that variable evaluations.

So, here's my two cents (Marty, apologies, as I think I'm copying some  
of your idea, but I needed my own stream of consciousness post).  Why  
not use a block tag, much like autoescape, to indicate that all  
variables in this scope are required, and tie it to a custom exception.

The benefits as I see it:

1) This doesn't actually cause a schism between development and  
production, as the block tag works the same in both cases.  If we  
really wanted a "this should be turned off in production no matter  
what", it could be a settings flag, although I'm -0 on that.
2) By using a custom exception, any other block tag or filter inside  
this scope could throw the same exception.  It wouldn't affect anyone  
normally as the template handler would catch it, but it would allow  
people building their own tags to get the same sort of functionality  
as internal variable resolutions, allowing block tags to force  
required.  (At least, when wrapped).
3) It's backwards-compatible.  People not using the block tag aren't  
affected.
4) It doesn't require any new syntactic sugar or assumptions.  It's  
just another block tag.  We might modify a few existing block tags or  
filters to be able to take advantage of it.

The negatives that I can think of right now:

1) It doesn't magically apply to all your templates.  I think this is  
a good thing, it's just like autoescape, if you're using it you  
probably know what you're doing and why, but I think some people may  
argue against it.

If people like this idea, I'll do a proof of concept.  It shouldn't be  
horrific, the templating engine seems pretty extendible in regards to  
adding new block tags.

gav


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[buriy]

Hi, I like to use TEMPLATE_STRING_IF_INVALID with <font
color="red">%s</font>, however such usage is discouraged.
I think that in production mode it's better to put no item into HTML
instead of 500 error in most of cases.
But there might be a method to mail admins somehow for important
fields having broken.
If TEMPLATE_STRING_IF_INVALID is able to show its string, you can make
a code to scream about error or mail admins or whatever. I bet you
don't ever need to patch django for this (maybe just monkeypatch a
bit).
Or, as an alternative, use unit testing to get rid of such problems as
you have experienced. It's considered good practice for dynamic-typed
languages (django templates plus views using them are dynamic-typed,
right?)

On Wed, May 14, 2008 at 8:58 PM, Simon Willison <[hidden email]> wrote:

>
> Hi all,
>
> Some time in late 2003, Adrian and I decided that errors in templates
> were best handled silently - the idea was that it would prevent
> untrained template editors from being able to 500-error a site with a
> typo.
>
> Is it too late to reconsider this decision, four and a half years
> later? I can't think of a single time this feature has helped me, and
> plenty of examples of times that it has tripped me up.
>
> Today's example: a <form action=""> tag that shouldn't have been
> blank. The code looked like this:
>
> <form action="{% url something-with-a-typo %}">
>
> If you look at Django's URL tag implementation, you can see why:
>
> http://code.djangoproject.com/browser/django/trunk/django/template/defaulttags.py?rev=6996#L364
>
> The code catches the NoReverseMatch exception and silences it,
> outputting an empty string instead.
>
> Silent errors are bad. If we were to remove them, how much of a
> negative impact would it have on the existing user base?
>
> Cheers,
>
> Simon
>
>
>
> >
>

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: [hidden email]

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jeff Anderson-6]

Hello!

Not that I have a vote, but I do have an idea...

Ken Arnold wrote:
> 5. Variable lookups, and everything else, never cause render() to
> fail, but insert an easy-to-catch and easy-to-bypass error string in
> the output.
<snip>
>
> Thoughts?
>  

Another option for easy-to-catch and easy-to-bypass error string display
would be to add error strings to a list on the fly (save them for a bit
later).
The template errors/warnings are not reported by default. To get to the
errors, you would use a tag, maybe something like: {% display_errors %}
Another behavior is that it could spit out the errors at the end of the
document generated by the template-- maybe when DEBUG=True? This creates
malformed documents in some cases, but many browsers can/will display
the text anyway.

I could have a template something like this:
<html><head><title>{{ page.title }}</title></head>
<body>
Welcome to my site, {{ user.first_name }}!
<div class="errors">{% display_errors %}</div>
</body>
</html>

that generates a document like this:

<html><head><title></title></head>
<body>
Welcome to my site, !
<div class="errors">Warning: page.title is undefined on line 1 of
index.thtml
Warning: user.first_name is undefined on line 3 of index.thtml</div>
</body>
</html>

My guess that the problem with this implementation is that it'd have to
make two passes to output all the errors that display_errors has to
list. It'd be silly to only report errors that happen before the tag occurs.

Of course some optimizations could be made so that display_errors could
look like: display_errors.as_html, or display_errors.only_debug (to only
display them when DEBUG=True), etc...

Thanks!

Jeff Anderson

[Christopher Allan Webber-2]

I'm just going to chime in here that a lot of our older apps at our
work use Zope Page Templates.

Largely we've found ZPT pages to be less pleaseant in all regards
*excepting* the fact that they never, ever silently fail.  Just as
your code fails when there's a problem, so do your templates.  It's
easy to see exactly where the problem is.  In django, sometimes it can
be a total mystery.  Sometimes you don't even know there's a problem
at all.

Thus I'm hugely +1 on this no-silent-failures bit, whether optional or
not.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[John Lenton]

On Wed, May 14, 2008 at 7:19 PM, Christopher Allan Webber
<[hidden email]> wrote:

>
> I'm just going to chime in here that a lot of our older apps at our
> work use Zope Page Templates.
>
> Largely we've found ZPT pages to be less pleaseant in all regards
> *excepting* the fact that they never, ever silently fail.  Just as
> your code fails when there's a problem, so do your templates.  It's
> easy to see exactly where the problem is.  In django, sometimes it can
> be a total mystery.  Sometimes you don't even know there's a problem
> at all.
>
> Thus I'm hugely +1 on this no-silent-failures bit, whether optional or
> not.

I'm very much on the +1 to no silent failures ever side, but one thing
that makes it work in ZPT is the |nothing thingie, that allows you to
explicitly ask for silence when needed.

--
John Lenton ([hidden email]) -- Random fortune:
The trouble with a lot of self-made men is that they worship their creator.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Alex Gaynor]

I'd be +1 on this, on the condition that there be some way to supress
errors, something like this.

{% for item in list %}
{{ item.title }}
{% silent %}
{{ item.owner }}
{% endsilent %}
{% endfor %}

On May 14, 11:03 pm, "John Lenton" <[hidden email]> wrote:

> On Wed, May 14, 2008 at 7:19 PM, Christopher Allan Webber
>
> <[hidden email]> wrote:
>
> > I'm just going to chime in here that a lot of our older apps at our
> > work use Zope Page Templates.
>
> > Largely we've found ZPT pages to be less pleaseant in all regards
> > *excepting* the fact that they never, ever silently fail.  Just as
> > your code fails when there's a problem, so do your templates.  It's
> > easy to see exactly where the problem is.  In django, sometimes it can
> > be a total mystery.  Sometimes you don't even know there's a problem
> > at all.
>
> > Thus I'm hugely +1 on this no-silent-failures bit, whether optional or
> > not.
>
> I'm very much on the +1 to no silent failures ever side, but one thing
> that makes it work in ZPT is the |nothing thingie, that allows you to
> explicitly ask for silence when needed.
>
> --
> John Lenton ([hidden email]) -- Random fortune:
> The trouble with a lot of self-made men is that they worship their creator.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Simon Willison-2]

On May 14, 3:51 pm, Ken Arnold <[hidden email]> wrote:
> 4. Other tags and filters, like include, ssi, and truncatewords (from
> a quick scan) that perform some function that could fail, should mark
> that failure very clearly in the output. (Those two currently do, but
> the error string is easy to miss if buried in a mess of other code.)
> 5. Variable lookups, and everything else, never cause render() to
> fail, but insert an easy-to-catch and easy-to-bypass error string in
> the output.

There are a few problems with inserting error output in the template
rather than raising an exception, the most important of which is that
you won't get an HTTP 500 error code so the problem won't be caught in
your server logs. Also, there are a number of situations where the
error output won't be visible in the browser - if it occurs within a
<script> tag or an HTML attribute, for example.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Michael Elsdörfer-2]

> I'd be +1 on this, on the condition that there be some way to supress
> errors, something like this.
>
> {% for item in list %}
> {{ item.title }}
> {% silent %}
> {{ item.owner }}
> {% endsilent %}
> {% endfor %}

That seems very clunky to me. If going down that route, I'd prefer to
either enable filters to catch exceptions, so {{ item.owner|default }}
can work, or maybe use some sort of syntax extension to silence
errors, say for example {{ @ item.owner }}

Michael
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Nicolas Lara]

I've been thinking about this issue, so here are some thoughts:

I like Jeff's idea on inserting the results into the template. I agree
also that the errors in-place pose problems since, as Simon commented,
the errors would not be visible in some cases.

Also the fail silently feature _can_ be _very_useful I've been using
lately a template engine that doesn't have this feature and have been
missing it a lot.

I would say that a throw-errors-by-default policy could be very good
as long as it can be overridden.

How about using something like what mark_safe does for escaping:
so
{{ article.subtitle|or_none }}   (naming could be changed: safe? trust?)
would behave as the current template code, failing silently.

If the filter is not used the error would be shown in-place and, if
the user wants to aggregate the errors in only one place in the
template or see errors that are inside <script> tags (among others),
he could use another tag like:
{% aggregate_template_errors %}

that would result in a list of errors and the places they appear in
(maybe even a snippet of the failing block of the template), removing
the errors that were to be shown in place.

Also this behaviour should change to the always-fail-silently one when
DEBUG=false.

To me this approach is very clean and would keep the backward
compatibility on production sites. Development sites would probably
need some changes to adjust to the new behaviour, but, come on!, they
are still on development!, changes are suposed to happen :)

Well, there are my two cents, let me know what you think,



On Thu, May 15, 2008 at 10:30 AM, Simon Willison
<[hidden email]> wrote:

>
>  On May 14, 3:51 pm, Ken Arnold <[hidden email]> wrote:
>  > 4. Other tags and filters, like include, ssi, and truncatewords (from
>  > a quick scan) that perform some function that could fail, should mark
>  > that failure very clearly in the output. (Those two currently do, but
>  > the error string is easy to miss if buried in a mess of other code.)
>  > 5. Variable lookups, and everything else, never cause render() to
>  > fail, but insert an easy-to-catch and easy-to-bypass error string in
>  > the output.
>
>  There are a few problems with inserting error output in the template
>  rather than raising an exception, the most important of which is that
>  you won't get an HTTP 500 error code so the problem won't be caught in
>  your server logs. Also, there are a number of situations where the
>  error output won't be visible in the browser - if it occurs within a
>  <script> tag or an HTML attribute, for example.
>
>
> >
>

--
Nicolas Lara

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---