A view's action is dependent on the request method. When overriding the method (e.g. to generate a form for a POST request on a GET call to the browseable API), the action should be updated as well. Otherwise, viewset functions may be in a weird limbo state where a 'list' action has a POST method.
Django's `HttpResponse` class checks for the `status` param when it's
initialized, if it's `None` it uses the class attribute
`status_code` and thanks to that we can do things like:
```
class BadRequest(HttpResponse):
status_code = 400
```
Now, that doesn't work when inheriting from rest-framework's `Response`:
```
class BadRequest(rest_framework.response.Response):
status_code = 400 # Bad, it's always ignored
```
Because a default status of `200` is being specified in
`rest_framework.response.Response`. I think is more Django-friendly to
just leave that status default value to `None` and leave the
responsibility of choosing its value to the parent class: `HttpResponse`.
While experimenting with extending DRF, I found that the login page
1) had no title, and 2) duplicated <head> info from base.html.
This change adds a new {% block body %} to the base.html template
which allows override of the entire html <body>. login_base.html
has its duplicated head info stripped, and now extends base.html
to share common html <head> templating.
As part of this change, pretify.css is unnecessarily added to
login_base.html. If this is deemed a problem, it will be easy to
block that css out, and have login_base.html override the block.
Ideally, I would have liked to create a new api_base.html that extends
base.html, move the api specific logic into that template, and leave
base.html content agnostic, to truely be a unifying base for all DRF
pages. But this change would break current apps that override
api.html and expect base.html to be the immediate super template. :/
This change is benificial because it:
- removes duplication of header declarations (mostly css includes)
- adds a html title to the login page
- standardizes html header info across all DRF pages
Docs are updated to reflect the new structure.
...by passing through any extra *args and **kwargs
to the parent constructor.
Previously one couldn't assign help_text to a
SerializerMethodField during construction.
