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 <[EMAIL PROTECTED]>
> wrote:
>>
>> On Wed, May 14, 2008 at 9:07 AM, Simon Willison <[EMAIL PROTECTED]
>> > 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
> [EMAIL PROTECTED]
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
