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

WIP.

This commit is contained in:
Víðir Valberg Guðmundsson 2023-06-21 00:06:46 +02:00
parent 0e927e30a8
commit 08e200e1e9
1 changed files with 0 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
content/django-view-decorator.md
View File

@ -191,25 +191,6 @@ This opens up a quite nifty possibility of injecting URLs into a namespace from
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.