On 03/12/10 22:50, Russell Keith-Magee wrote:
This proposal has come up before and has historically been rejected;
however, your point about class-based views makes it a lot harder to
give the standard responses.
Yup; this email came directly from using the new CBVs and hitting this
very problem multiple times. In the interim I'm writing a small app +
middleware to do a similar thing, which will be close to good (apart
from not integrating as well).
I've only got one piece of feedback, regarding the
HTTP_EXCEPTION_CLASSES idea. I can see two problems with this:
* Using a single system setting means that you can't install custom
handlers on a per-URLPattern basis, which is currently possible with
handler404/500
Very true, although I don't want to expose handlers as "random variables
in the urls namespace", that's always seemed like a hack (especially the
part where we encourage people to import * from the defaults)
* To me, it would make more sense to implement HTTP_EXCEPTION_CLASSES
as a stack of instances, rather than as a 500->, 404->, 403-> dispatch
mechanism. My reasoning for this is that it seems to me that one of
the most common patterns would be to write a single exception handling
class, containing all the handler methods, and 'just install the damn
thing'. As you've proposed it, I'd need to install the same class in
(potentially) 5 or six locations.
This isn't so much of a problem at the moment because there's only two
handlers, and they aren't combined into a single class, but if we're
moving to needing handlers for all the different exception types, this
could get onerous. Using 'hasattr('handle404')' on a stack of
exception handling class instances feels like it would be a more
natural interface for this sort of thing.
Good point - one instance also frees us up to make the assignment of
what to use slightly nicer (we could always move to using error_handler
or something in the urls.py locals, if nothing else)
However -- as you note -- I don't think this needs to be rushed as a
1.3 thing. There is something to be said for letting the dust settle
on the 1.3 CBV API to see where the holes are, and fixing them in the
1.4 cycle
Definitely; I plan to get this half-done as an external app first. I
just wanted to see what people's initial reactions were (namely, "class
based views makes this a more real issue").
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@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.
