Support registering url routes via @decorator. (Locality of Behaviour)

[collinanderson]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Support registering url routes via @decorator.

@view(paths="foo/", name="foo")
def foo(request: HttpRequest) -> HttpResponse:
    return HttpResponse("foo")

This blog post describes it better than I can: https://valberg.dk/bringing-locality-of-behaviour-to-django-views-and-urls.html

Forum post discussion here: https://forum.djangoproject.com/t/bringing-locality-of-behaviour-to-django-views-and-urls/21765

Problem

New Django projects can be complicated and have lots of files, with code split between views.py and urls.py. It would be nice for beginners and simple projects to avoid needing a urls.py file and do all url registering in the views.py file itself.

Some people also consider this approach to be more DRY (don't repeat yourself).

Request or proposal

request

Additional Details

It shouldn't be the main recommended approach, as there are clearly disadvantages discussed in the forum post. But rather this should be an alternative option for for those who prefer this style.

Flask, FastAPI, and Django Ninja all use this approach, so it would be nice to have this method available for those who are more comfortable working with that style.

I think it could also allow for a less "heavyweight" project style by not needing a separate urls.py.

Implementation Suggestions

The "Behind the scenes" section of the blog post has some implementation details. https://valberg.dk/bringing-locality-of-behaviour-to-django-views-and-urls.html#behind-the-scenes

[github-actions]

Thank you collinanderson for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[nanuxbe]

I feel this is something you'd want to use mostly for smaller projects. And if my assumption is correct then, would there be an advantage of using this compared to using the whole of nanodjango which provides this functionality?

I would personally like to see (part of) nanodjango made useless (in a good way) by bringing them into django (possibly as a corollary to the new command)