Custom error templates in a single Django application

[José Luis Patiño Andrés]

Hello, everybody.

I think there is a limitation in the customized error views that can be reviewed. There is the feature of customizing error pages (like 404 or 500 errors) for a single app.

I will explain the problem: if you want to write a custom template for those errors, following the Django documentation (​http://docs.djangoproject.com/en/1.2/topics/http/views/#customizing-error-views ) you can get it specifying the 'handler404' and 'handler500' in the urls.py file and creating the appropiate views for it. But this does not work when you have some apps with their owns urls.py files and you try to do it in a single app. The developer is forced to use only one customized error view for the whole Django project.

I have searched in internet to make me sure that is not possible, and I met other django programmers that have found the same problem. There are more or less tricky solutions to this specific request, but the ideal should be to do it in the same way that we do for the whole project, as it is explained in the Django documentation.

I think this is the correct place to make this kind of requests. If it's not, please excuse me. I am not requesting for tech support, My ticket is only a feature request.

Thanks a lot for your time.

Cheers.
Jose

[Russell Keith-Magee]

It's not entirely clear to me what is being proposed here. At a high level, having multiple handlers for 404 and 500 errors sounds like a reasonable idea, but I'm not sure how this would be interpreted in practice.

In particular -- what delineates the "app" boundary that decides which error page is used? An "App" isn't something that has a clear boundary -- it's just a collection of views. Consider the following pathological, but entirely legal case:

urlpatterns = patterns('',
    (r'^foo/', include('app1.urls')),
    (r'^foo/', include('app2.urls')),
)

How do you define a custom 404/500 handler for 'app1', and under what circumstances is it invoked?

[José Luis Patiño Andrés]

Okay, your example case is the best way to explain my situation, because is just that I did in the Django project which I am working :)

So, we have two Django apps in the same project, app1 and app2, each of them with its own 'urls.py' file where the URL routing is specified. My case is that I want to specify a different 'handler404 = ...' and a 'handler500 = ....' in each 'urls.py' file. Then when you type, for example, 'http:/mysite.com/app1/BAD_URL' you get the 404.html template specified in the app1 views, and if you type '​http://mysite.com/app2/BAD_URL' you get the 404.html template specified in the app2 views. And the same for the 500 errors.

Now, this is not possible because you only can do this in the project 'urls.py' and the handler404 and handler500 must be the same for all the applications involved in the project.

This is what I am referring when I asked for a custom error handler for an app.

Cheers.
Jose

PD.: I post this here in response to Comment nº1, because I can't post it doing 'Reply'. A Spam alert blocks my reply, telling that the content of my message is spam suspicious :P

[Adrian Holovaty]

So basically jose is saying you should be able to override the global handler404 and handler500 within a "child" urls.py. I think this wouldn't be worth adding, because it would be adding cruft to an already-crufty API. (I'd like to make a cleaner way of doing handler404/handler500 down the road -- it seems crufty as-is.)

jose: You can accomplish what you want by returning a custom HttpResponse class from your view with status_code 404, like this:

response = render_to_response('custom_404_template.html', context)
response.status_code = 404
return response

If you don't want to do this from every view, you can write a middleware that catches 404s and does different things depending on context/URL.

[Russell Keith-Magee]

@jose -- Look very closely at my example. I deliberately mounted 2 included URLs at the same base -- /foo. Lets say I browse to /foo/bar. It doesn't match anything in app1.urls or app2.urls. Do we display the app1.handler404 or the app2.handler404? Both app1.urls and app2.urls match the /foo prefix -- how do we disambiguate between the two?

I agree with Adrian -- I'm not convinced that this can be done in a non-crufty way. There might be room to do this sort of thing if we rework the way URLs are defined, but given the current structure, I'm not sure it can be done cleanly and unambiguously.