I'm not sure suppressing templates errors for the admin is such a
great idea.
I work on two projects[1] where I would lose a useful debugging
information and
it would be the same lost to anyone working on the admin or extending
the admin.
Of course we could use a settings to toggle on/off the admin error
suppression,
but that would mean another setting.. which is to be avoided.
Maybe a better approach would be to simply mark the fallback string as
safe.
Then it would be possible to suppress them like so:
TEMPLATE_STRING_IF_INVALID = "<!-- Invalid var -->"
This would have the benefit to be more flexible:
TEMPLATE_STRING_IF_INVALID = "!! Invalid var !!" # settings_dev.py
TEMPLATE_STRING_IF_INVALID = "<!-- Invalid var -->" # settings_prod.py
But this would have side effects on the non-admin templates too.. so
it's not ideal.
Maybe something like this:
TEMPLATE_STRING_IF_INVALID = {'default: '!! Invalid var !!',
'django.contrib.admin': ''}
I think it would pretty much solve the problem, preserve backward
compatibility/behavior and
even allow to suppress errors for any other apps.
[1] https://github.com/sehmaschine/django-grappelli
http://jqmobile-sandbox.motion-m.ca/
--
Maxime Haineault
On Aug 24, 7:39 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Wed, Aug 24, 2011 at 11:44 PM, Ole Laursen <o...@iola.dk> wrote:
> > Hi!
>
> > I have a project where setting TEMPLATE_STRING_IF_INVALID has been
> > invaluable in finding problems (for various reasons). The caveat
> > mentioned in the docs don't kick in here because no templates are
> > inherited from elsewhere. Except the admin which unfortunately breaks
> > down in some places.
>
> > I realize there's been a big discussion before about the merits of
> > error suppression. No need to repeat that.
>
> > But is it really not possible to fix admin in the few places it's a
> > problem? Those I've seen so far have one-line fixes where you add an
> > empty variable to the context. Seems harmless to me. I realize
> > cluttering the template itself with a {% if var %} is ugly. No need to
> > go there.
>
> > I don't mind writing a patch for the cases that bother me, but won't
> > do it unless somebody is willing to apply it?
>
> On principle, I have no objection to the idea of making the admin
> templates more robust in the presence of TEMPLATE_STRING_IF_INVALID;
> adding dummy values in the context sounds like a reasonable approach
> -- *if* doing this doesn't undermine broader error handling in the
> templates.
>
> Also -- dummy values may not be the only option. There's also |default
> and |default_if_none filters.
>
> However, in order to evaluate the details, I'd need to see them --
> which unfortunately means a patch (or, at least, an indicative start
> of a patch).
>
> I fully appreciate your desire not to waste your time, though --
> there's no point making a patch if it will be ignored. I would suggest
> the best approach here is to attack this in stages. Provide a patch
> that fixes a small number of uses in a limited number of key
> templates, and poke around on django-dev or on IRC to ask for a
> review. Once that initial patch is approved and/or applied, expand the
> patch until it covers all problematic uses.
>
> Russ %-)
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
