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 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
-~----------~----~----~----~------~----~------~--~---
