On Mon, 2006-07-03 at 22:49 +0800, Russell Keith-Magee wrote:
>
> Hi all,
>
> I've been tracking bug #2237, which has revealed a few weird cases in
> the way the TEMPLATE_STRING_IF_INVALID setting gets used. These cases
> are easy to find - put TEMPLATE_STRING_IF_INVALID='invalid' in your
> settings file, load the admin page, and watch the breakage that
> ensues.
>
> The breakage stems from a number of problems:
>
> 1) If you have TEMPLATE_STRING_IF_INVALID='foo', and your template
> contains an {%if key%}, and the context does _not_ contain 'key', the
> 'if' will still return True, because the resolving process says 'key'
> exists - with the value 'foo'.
This is ticket #1338, by the way.
Glad you're picking this up, because every time I look at it, I keep
wandering down the path you have and thinking "this is messy."
> 2) Use of TEMPLATE_STRING_IF_INVALID is not disabled if
> TEMPLATE_DEBUG=False. As a result, if you have such a string defined
> in the settings file you use to run the unit tests, 18 of the template
> tests fail - even though the template tests specifically disable
> template debug to ensure consistent results.
I thought this was kind of the point of the string: there was a way,
even in production, so that you could replace a missing variable with a
default value.
> 3) Ultimately, TEMPLATE_STRING_IF_INVALID isn't particularly useful
> for diagnosing problems; it is a catch-all warning message, which
> indicates any one of a large number of problems, but doesn't provide
> any additional detail. In some cases ( e.g., when ObjectDoesNotExist
> is thrown), the string is used as an intentional silent failure
> message.
Agreed. I have never used TEMPLATE_STRING_IF_INVALID (that I know of),
so I don't feel able to speak to its merits. But I think you make a good
case why it's not instantly useful as a debugging tool. I'm not
convinced it is useful as a production tool (what string other than the
empty string would I always want to put in my templates in those
cases?), so we arrive at your conclusions.
Others may have better experiences, though.
> I would like to propose the following three changes:
>
> 1) Modify {%if %} statements to assume a value of False if context
> doesn't contain a key, regardless of debug settings.
Strongly agree.
>
> 2) Remove TEMPLATE_STRING_IF_INVALID as a configurable setting, and
> replace it with a set of fixed messages that more accurately describe
> the template problem; for example: "(UNKNOWN CONTEXT: '%s')",
> "(INVALID NUMBER: '%s')", etc. These messages would be short, context
> sensitive, and unique to each type of template problem.
>
> 3) Only display the template error messages if TEMPLATE_DEBUG is
> enabled.
These two kind of go together: you are proposing making
son-of-TEMPLATE_STRING_IF_INVALID more of a debugging aid than a
production tool. I can see the benefits here, but, as I said, I'm not a
big user of the current functionality, so I might be missing something.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
