CODEWITHSUNDEEP
django
KobeJohn
KobeJohn

Reputation: 7545

Why does Django not pass on error messages with the default 404 view?

(Context: I'm still very new to both Django and web development.)

1) Could someone explain the reasoning for the following statement? This Q/A answered the question of how to deal with it, but not why it might be a good/bad idea.

The docs state, "The page_not_found view should suffice for 99% of Web applications, but if you want to override it, you can specify handler404 in your URLconf".

That is, the page_not_found view only passes on the requested URL and ignores any message you provide when raising an exception. It seems to me that having the option to provide helpful hints to the 404.html template by default would be good for everyone.

2) I'm currently making a custom view so that I can pass on helpful messages for the following situation. Is there some reason I shouldn't?

I'm using matrix URLs so the base resource is a normal hierarchical URL followed by matrix options in the basic format of: ;filter_type1=item:value,item:value;filter_type2=item:value...

So it is quite easy to provide helpful messages based on how far along the parsing gets before having an error. It seems helpful to me to pass on a message such as the following:

Apologies if I missed this explanation elsewhere. I've looked and I asked on google django-users but got no replies.

Upvotes: 2

Views: 445

Answers (3)

Kevin Fegan
Kevin Fegan

Reputation: 1290

I think the reason you are having trouble understanding this is, you are trying to mix 2 different issues.

First, is the issue of whether the actual page was found or not.
Second, is the issue of whether the parameters provided were valid or not.

So, if the (partial) url is: 

    .../whatever/?param1=value1&param2=value2

If the page /whatever/default is not found, you will (should) be shown a "404 Page not found" type of error message. In this case, you can't tell if the parameters or values provided were correct. The requested page doesn't exist, so you don't know which page the parameters were meant for. You can't even assume that the correct domain name was specified. There may be many arbitrary domains, urls, and pages where the parameters are valid, and many others where the parameters are invalid.

If the page /whatever/default is found, then:
If specifying the wrong parameters might cause that page to load/redirect a non existent page, then that should be prevented by that page. If necessary, it should be up to that page to validate the parameters provided, and take appropriate actions and show appropriate messages.

Upvotes: 1

Matthew Schinckel
Matthew Schinckel

Reputation: 35619

If your data is coming in like:

http://example.com/foo;bar;baz

Then you are doing it wrong :)

You then need to use regular expressions to parse the data that is to be processed.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

(Zawinski, 1997)

Instead, as pastylegs suggests, use GET parameters.

Even better, make use of the django form handling and:

  • create a form, that has validation rules
  • render the input page from that form
  • parse the user input using the form
  • display data if form was valid, else display validation errors alongside user input

You can do this with GET requests, or POST requests. POST has the advantage of having 'clean' urls, and longer data body. GET means that urls can be bookmarked.

What this all comes down to is using the right parts of the framework for the right tasks. URL routing uses regular expressions to work out which URL hits which view. The simpler you make the url patterns, the easier they will be to maintain. User input should be handled by forms.

Upvotes: 1

Timmy O'Mahony
Timmy O'Mahony

Reputation: 53981

I'm not really sure what the question is. The page_not_found view is basic by default because there aren't that many situations where you need to explain why the page wasn't found except that it wasn't.

I presume by 'matrix options' you mean URL/GET parameters like:

http://domain.com/page/?option1=value&option2=value..

Instead of throwing a 404 if they enter an incorrect combination of parameter, why not default to the base url/template (http://domain.com/page/) with an error message saying "Option1 can only be x,y,z". This way they are presented with a familiar page and can retry their selection without having to navigate back from a 404 page (and it isn't so confusing as to why it didn't work).

You can use django's messaging framework to easily accomplish this (I've done so in the past). Pass an error message to the template when you are checking the parameters in the view.

Upvotes: 1

Related Questions