On 04/12/10 09:15, Tim Diggins wrote:
View& template:
look for a handle{{status_code}} variable, falling back to
handle_exception. The generic handle_exception in non-DEBUG looks for
a specific "{{status_code}}.html" template, but falls back to a (say)
"http_exception.html" template. (there woul
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 probl
(and apologies, (just after I hit send) I realized that I may be off
mark, as I'm not working with 1.3/dev in my current apps... so I may
be missing some critical changes in 1.3.)
On Dec 4, 9:15 am, Tim Diggins wrote:
> This sounds good to me, but can I give an additional or alternative
> excepti
This sounds good to me, but can I give an additional or alternative
exception handling, for consideration (feels a bit simpler, both to
use and to implement):
Exceptions:
When catching an exception in BaseHandler.get_response look for a
"status_code" attribute (getattr(e, 'status_code', 500)) then
On Fri, Dec 3, 2010 at 10:36 PM, Andrew Godwin wrote:
> So, one of the complaints I've heard from a few people now is the fact
> that 404 is the only thing one can raise as a HTTP error - there are
> plenty of others, such as 403 and 405, that could be useful to raise
> back to the client.
>
> Thi
So, one of the complaints I've heard from a few people now is the fact
that 404 is the only thing one can raise as a HTTP error - there are
plenty of others, such as 403 and 405, that could be useful to raise
back to the client.
This didn't used to be much of a problem with function-based views -
