8.9 KiB
Title: Bringing Locality of Behaviour to Django Views and URLs Date: 2023-06-20 Status: hidden Tags: django, views, locality-of-behaviour Slug: bringing-locality-of-behaviour-to-django-views-and-urls Authors: Víðir Valberg Guðmundsson Summary: Introducing django-view-decorator, a Django package which brings Locality of Behaviour to your Views and URLs
It seems that "The Location of Behaviour principle" (shortened as LoB) is gaining traction these days. This has given me the urge to try to influence the direction of Django to bring more LoB to the connection between views and URLs.
But first, what is "LoB"? The principle is coined by the author of HTMX in a short, but great, essay. The principle states:
The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code
Given a very simple view:
:::python
# views.py
def foo(request: HttpRequest) -> HttpResponse:
return "bar"
It is not apparent how to access the view with HTTP. To see what URL the view is tied to we have to look at urls.py:
:::python
# urls.py
from django.urls import path
from .views import foo
urlspatterns = [
path("foo/", foo, name="foo")
]
Carlton Gibson mentions this in is talk at DjangoCon Europe 2023, and why this means that he often puts view code in the same file as his URLs.
But why this disconnect? Other frameworks, like Flask and FastAPI use a rather simple "pattern" using a decorator which puts the URL information where the view is defined:
:::python
# flask_example.py
from flask import Flask
app = Flask(__name__)
@app.route("foo/")
def foo():
return "bar"
Just by looking at the decorator tied to the foo function we know that we can access it via foo/.
Another pitfall due to this disconnect is that there is no guarantee that a view has a URL pointing at it.
Can we apply the same pattern to Django? Yes we can!
Introducing django-view-decorator!
Basics
First we setup our project URLconf to include URLs from django-view-decorator:
:::python
# project/urls.py (this is what we point the ROOT_URLCONF setting at)
from django.urls import path
from django_view_decorator import include_view_urls
urlpatterns = [
path("", include_view_urls()),
]
Then we can use the view decorator like so (we dive deeper in what the decorator does later on):
:::python
# foos/views.py
from django_view_decorator import view
@view(paths="/foo/", name="foo")
def foo(request: HttpRequest) -> HttpResponse:
return "bar"
We now have information about how the view is to be accessed right there next to the view itself.
Even class-based views are supported:
::python
@view(paths="/foo/", name="foo-list")
class FooList(ListView):
model = Foo
More advanced usage
Multiple URLs can point at the same view, and you might have noticed that the argument is the plural paths. This is because we can pass a list of paths which point at the same view. Like so:
:::python
@view(
paths=[
"/foo/",
"/foo/<int:id>/",
],
name="foo",
namespace="foos",
)
def foo(request: HttpRequest, id: int | None = None) -> HttpResponse:
foos = Foo.objects.all()
if id:
context = {"foo": get_object_or_404(foos, id=id)}
template_name = "foo_detail.html"
else:
context = {"foos": foos}
template_name = "foo_list.html"
return render(
request,
template_name=template_name,
context=context
)
Looking at the view we can grok that it is exposed on two paths, under the foos namespace, one which lists all Foo objects and one which given an integer gives us the detail for a single Foo. That's pretty powerful if you ask me!
If we want different names for each path we can simply apply the decorator multiple times:
:::python
@view(
paths="/foo/",
name="foo_list",
namespace="foos",
)
@view(
paths="/foo/<int:id>/",
name="foo_detail",
namespace="foos",
)
def foo(request: HttpRequest, id: int | None = None) -> HttpResponse:
...
Behind the scenes
So how does this work? Pretty much the same way as the django.contrib.admin module.
The django_view_decorator.apps.ViewDecoratorAppConf.ready method runs django.utils.module_loading.autodiscover_modules which looks for all views.py modules in installed apps and imports these. This means that when @view occurrences are loaded in, we can put the views and associated metadata into a registry which we then can ask to write our urlpatterns list for us.
So the @view decorator is quite similar to the well-known @admin.register decorator.
Namespaces and the power of factories
In our more advanced example you might have noticed the namespace="foos", which probably is going to quite tedious to repeat over and over again. One of the nice things about Django URLconfs is that we get namespacing by using the include function.
This is where the aptly named namespaced_decorator_factory comes into the picture. Let us look at an example:
:::python
# foo/views.py
from django_view_decorator import namespaced_decorator_factory
foo_view = namespaced_decorator_factory(
namespace="foos",
base_path="foos/",
)
@foo_view(paths="", name="list")
def foo_list(request: HttpRequest) -> HttpResponse:
return "foo list"
@foo_view(paths="<int:id>", name="detail")
def foo_detail(request: HttpRequest, id: int) -> HttpResponse:
return "foo detail"
By calling namespaced_decorator_factory we get a specialised decorator for our namespace and we can even provide it with a path which will be prepended to all URLs registered using it.
This opens up a quite nifty possibility of injecting URLs into a namespace from anywhere. For example:
:::python
# app_1/views.py
app_1_view = namespaced_decorator_factory(
namespace="app_1",
base_path="app_1/",
)
# app_2/views.py
from app_1.views import app_1_view
@app_1_view(
paths="my-custom-view/",
name="custom-view"
)
def custom_view(request: HttpRequest) -> HttpResponse:
return "I'm in another namespace"
Now we can treat custom_view as if it was a part of the app_1 namespace. Ie. reverse("app_1:custom-view") would give us app_1/my-custom-view/. Neat!
One decorator to rule them all?
One feature of django-view-decorator which I'm not sure if makes sense, is the idea to embed other decorators into it. For example, instead of:
:::python
@view(paths="/foo/", name="foo")
@login_required
def foo(request: HttpRequest) -> HttpResponse:
return "bar"
We can just write:
:::python
@view(paths="/foo/", name="foo", login_required=True)
def foo(request: HttpRequest) -> HttpResponse:
return "bar"
At the time of writing login_required, staff_required and permission checking is included in the decorator. But either the decorator should support, at least, all decorators in django.views.decorators, or not at all.
The path to Django core
So, as I wrote initially, I have a mission to try to get this pattern into Django core. This is not going to be an easy feat.
To cite Carlton Gibson from the previously mentioned talk:
Put it in a third party package. See if there is community interest. Then maybe it gets merged to the core if there is.
So this is what I'm doing.
- Write the third party package - check!
- Write a blog post - check!
- Gather community interest - ongoing
- Merge!
How could this be manifested in Django?
I haven't started the work to write a PR to get this into Django just yet, but here are some of my initial thoughts on how this would work in Django.
First of I would probably locate the decorator at django.views.view. But it might event be a opt-in feature and live in django.contrib.view_decorator or something similary. Having it as a contrib package would make it "cleaner" to solve the "where do we put the auto discovery?" - it would be in django.contrib.view_decorator.apps.ViewDecoratorAppConfig.ready.
One idea I'm going to explore in django-view-decorator is to write an AppConfig subclass which uses namespaced_decorator_factory to generate a decorator for an app. This way there would be a way to get a decorator for a specific app using the "applications" framework in Django.
What do you think?
So now I'm throwing the ball to the Django community!
What do you think? Should we just keep seperating views and URLs into different files or am I on to something? Does my solution have any major downsides which I have been blind to?
Come discuss on the Django forum in this dedicated thread: