valberg/valberg.dk
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

wip

Browse source
This commit is contained in:
Víðir Valberg Guðmundsson 2023-06-21 14:00:48 +02:00
parent 6e4407218e
commit b27c0f4fb7
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
content/django-view-decorator.md
View file

@ -1,5 +1,5 @@
Title: Bringing Locality of Behaviour to Django Views and URLs Title: Bringing Locality of Behaviour to Django Views and URLs
Date: 2023-06-20 Date: 2023-06-21
Status: hidden Status: hidden
Tags: django, views, locality-of-behaviour Tags: django, views, locality-of-behaviour
Slug: bringing-locality-of-behaviour-to-django-views-and-urls Slug: bringing-locality-of-behaviour-to-django-views-and-urls
@ -19,7 +19,7 @@ Given a very simple view:
:::python :::python
# views.py # views.py
def foo(request: HttpRequest) -> HttpResponse: def foo(request: HttpRequest) -> HttpResponse:
return "bar" return HttpResponse("foo")
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: 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:
@ -80,7 +80,7 @@ Then we can use the `view` decorator like so (we dive deeper in what the decorat
@view(paths="/foo/", name="foo") @view(paths="/foo/", name="foo")
def foo(request: HttpRequest) -> HttpResponse: def foo(request: HttpRequest) -> HttpResponse:
return "bar" return HttpResponse("foo")
We now have information about how the view is to be accessed right there next to the view itself. We now have information about how the view is to be accessed right there next to the view itself.
@ -185,11 +185,11 @@ This is where the aptly named `namespaced_decorator_factory` comes into the pict
@foo_view(paths="", name="list") @foo_view(paths="", name="list")
def foo_list(request: HttpRequest) -> HttpResponse: def foo_list(request: HttpRequest) -> HttpResponse:
return "foo list" return HttpResponse("foo list")
@foo_view(paths="<int:id>", name="detail") @foo_view(paths="<int:id>", name="detail")
def foo_detail(request: HttpRequest, id: int) -> HttpResponse: def foo_detail(request: HttpRequest, id: int) -> HttpResponse:
return "foo detail" return HttpResponse("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. 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.
@ -211,7 +211,7 @@ This opens up a quite nifty possibility of injecting URLs into a namespace from
name="custom-view" name="custom-view"
) )
def custom_view(request: HttpRequest) -> HttpResponse: def custom_view(request: HttpRequest) -> HttpResponse:
return "I'm in another namespace" return HttpResponse("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! 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!