While tinkering with Wagtail (and inherently, Django), I found myself in no time with a very large views.py
file due to how Django sets up its endpoint management. For this reason, I decided I would attempt at segregating the responsibility of views.py
into separate files/classes, in order to make it easier to maintain and read.
The idea is close to an MVC pattern. Ideally there will be a Controller
that will implement the Action
(endpoint) logic, which will parse the request, its data, and will implement the necessary logic for the data lookup part. The result of this will be converted into a ViewModel
(Data class) which will be passed to a View
(Django template), ideally binding them together.
I have decided to implement a ControllerBase
(see below), that will be inherited by the rest of the Controllers in the solution.
All redundant logic, as well as the necessary methods needed in order to support Django's decorators, will be implemented and performed at ControllerBase
.
By default, the onRequest
method will be called by the URL binding in urls.py
(see 2 files below).
ControllerBase
also exposes 2 abstract methods that need to be implemented by the controllers inheriting it: onGet
and onPost
. These functions will be called respectively depending on the HTTP verb used in the request to the endpoint.
SampleController
implements ControllerBase
through its Actions
: SampleAction
and TestAction
.
Both actions are exposed in /test/{int}
and /sample/{int}
(see urls.py
below). Each individual Action
is a class that will implement the desired HTTP verb methods through the exposed abstract methods, such as onGet
and onPost
.
In the future, details will be added regarding how to implement the ViewModel
generation and the binding with the Django View
template.