Return to Answer

Added links to docs

Source Link

edit approved May 26, 2023 at 0:58

As you pointed out, often the specifics of what constitutes invalid request parameters is different enough for each view, and so including this type of code in each view is (I think) fine and not a DRY violation. It also self-documents the view by having code at the beginning that clarifies what the view expects to receive, either in the URL, GET, or POST, and that's worth something.

However, since there are some situations where very specific patterns might benefit from refactoring, I would defer to the Django code itself for a good guideline on when a decorator (your option #2) or a function (option #3) might be the better option:

Django uses view decorators for patterns like login validation, permissions validation, etc. Note that these are situations where the decorator doesn't need to pass results from its processing into the view itself.
Django provides functions (rather than decorators) to handle situations like get_object_or_404get_object_or_404, get_list_or_404get_list_or_404, etc. Note that in these situations, the view does need access to the results of the processing (namely, the instance). Those functions are implemented similarly to your option #3.3 (although I think #3.1 would equally work).

To sum up, option #1 is usually fine and very useful for self-documenting code, but for very specific patterns, determine whether the view needs access to the results. If so, option #3 is probably better (otherwise, option #2). If going with option #3, then 3.3 is the path Django takes, though 3.1 seems equally workable.

Side note:

You mentioned that you are currently returning a 500 response in these situations. A 500 response indicates that the server experienced an error, which is not the case here, and so it's an incorrect response code to deliver.

Instead do one of the following:

If your view got a captured URL parameter that is incorrect, then either a 404 should be returned (since that URL doesn't exist), or the view should return a 301 or 302 redirect to a good URL.
If the view received GET or POST parameters that are incorrect, then a 400 Bad Request response should be returned.

Django uses view decorators for patterns like login validation, permissions validation, etc. Note that these are situations where the decorator doesn't need to pass results from its processing into the view itself.
Django provides functions (rather than decorators) to handle situations like get_object_or_404, get_list_or_404, etc. Note that in these situations, the view does need access to the results of the processing (namely, the instance). Those functions are implemented similarly to your option #3.3 (although I think #3.1 would equally work).

Side note:

Instead do one of the following:

If your view got a captured URL parameter that is incorrect, then either a 404 should be returned (since that URL doesn't exist), or the view should return a 301 or 302 redirect to a good URL.
If the view received GET or POST parameters that are incorrect, then a 400 Bad Request response should be returned.

Django uses view decorators for patterns like login validation, permissions validation, etc. Note that these are situations where the decorator doesn't need to pass results from its processing into the view itself.
Django provides functions (rather than decorators) to handle situations like get_object_or_404, get_list_or_404, etc. Note that in these situations, the view does need access to the results of the processing (namely, the instance). Those functions are implemented similarly to your option #3.3 (although I think #3.1 would equally work).

Side note:

Instead do one of the following:

If your view got a captured URL parameter that is incorrect, then either a 404 should be returned (since that URL doesn't exist), or the view should return a 301 or 302 redirect to a good URL.
If the view received GET or POST parameters that are incorrect, then a 400 Bad Request response should be returned.

Source Link

answered Apr 20, 2015 at 10:52

Christian Abbott

Django uses view decorators for patterns like login validation, permissions validation, etc. Note that these are situations where the decorator doesn't need to pass results from its processing into the view itself.
Django provides functions (rather than decorators) to handle situations like get_object_or_404, get_list_or_404, etc. Note that in these situations, the view does need access to the results of the processing (namely, the instance). Those functions are implemented similarly to your option #3.3 (although I think #3.1 would equally work).

Side note:

Instead do one of the following:

If your view got a captured URL parameter that is incorrect, then either a 404 should be returned (since that URL doesn't exist), or the view should return a 301 or 302 redirect to a good URL.
If the view received GET or POST parameters that are incorrect, then a 400 Bad Request response should be returned.