Heya,
Thanks for the feedback. I quite like the explicit 'STATIC_URL' only
approach, although I think a lot of users would still run into a problem
there, because 'request' isn't also added in explicitly to the Context...
For context, my particular use case is a simple '500.html' template, that
extends a 'base.html' template. I don't use any other context in the base
template other than 'request' and 'STATIC_URL'. In the case of a 500 error,
I'd see the template render correctly, except that it'd look like the user
isn't logged in. Coming across that as a dev that'd confuse the hell out of
me the first time I came across it unless I already understood the 500
Context behavior, and it's not ideal from the end-user perspective either.
I'd imagine that plenty of other setups would have a similar setup, so you
could argue that returning this:
Context({'STATIC_URL': settings.STATIC_URL, 'request': request})
would be an okay thing to do in the default 500 handler.
Personally I think that'd probably be absolutely fine (and the most
sensible default 500 view), although the obvious counter argument is that
that's getting into the realms of special-case, rather than default-case.
(That's not my opinion, but it'd be a valid argument.)
What do you reckon?
Cheers,
Tom
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/Ac1EeU-n6xAJ.
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?hl=en.
