Opened 4 years ago

Closed 3 years ago

#15695 closed New feature (fixed)

Save ResolverMatch in HttpRequest

Reported by: nischu7 Owned by: nobody
Component: Core (Other) Version: 1.3
Severity: Normal Keywords:
Cc: real.human@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

In order to simplify the implementation of navigation systems within templates, the HttpRequest instance passed around in the request cycle should held a "url_name" property.

Example:
You define a url that looks like this one:

url(r'^$', 'core.views.dashboard', name='dashboard'),

You'll be able to get the name by accessing "request.url_name". This is more efficient than having to re-resolve the URL in the views/middleware classes/template tag implementations etc.

Attachments (1)

base.py.patch (1.1 KB) - added by nischu7 4 years ago.
patch of "django/core/handlers/base.py"

Download all attachments as: .zip

Change History (15)

Changed 4 years ago by nischu7

patch of "django/core/handlers/base.py"

comment:1 Changed 4 years ago by adrian

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Hmm, we'll have to think hard about whether to add another attribute to HttpRequest.

comment:2 Changed 4 years ago by nischu7

I appreciate your sceptical attitude in favor of Django's quality.
On the other hand, storing the "url_name" or even better, the whole ResolverMatch object returned by "RegexURLResolver.resolve" would make things more efficient since you won't need to re-resolve the URL in later phases.

comment:3 Changed 4 years ago by lukeplant

  • Type set to New feature

comment:4 Changed 4 years ago by lukeplant

  • Severity set to Normal

comment:5 Changed 4 years ago by julien

  • Needs documentation set
  • Needs tests set
  • Triage Stage changed from Unreviewed to Design decision needed

I'm a bit concerned about this as url_name would only be one part of the picture -- for this feature to be really useful and versatile you'd also need to pass along the url resolving parameters (args and kwargs), but then that would be even more stuff to cram into the HttpRequest object.

This is still an interesting idea though, so I'll mark as DDN in case another clean implementation can be suggested.

comment:6 Changed 4 years ago by nischu7

As I already stated in the 2nd comment, I'd just store the ResolverMatch object as it is since it contains everything we need (view callback function, args, kwargs, the url name, as well as the app name). Should I submit another patch?

comment:7 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:8 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:9 Changed 3 years ago by aaugustin

  • Summary changed from Add "url_name" to HttpRequest to Save ResolverMatch in HttpRequest

comment:10 Changed 3 years ago by aaugustin

#16087 is related.

comment:11 Changed 3 years ago by mrmachine

  • Cc real.human@… added

comment:14 Changed 3 years ago by Florian Apolloner <florian@…>

  • Resolution set to fixed
  • Status changed from new to closed

In b946db5241b924c72c1079ce30d9b368e2b82f07:

Fixed #15695 -- Added ResolverMatch to the request object.

Note: See TracTickets for help on using tickets.
Back to Top