Opened 7 years ago

Closed 6 years ago

#18753 closed New feature (fixed)

Views should be given the instance namespace retrieved during the resolve process

Reported by: GaretJax Owned by: nobody
Component: Core (URLs) Version: 1.4
Severity: Normal Keywords: namespace current_app
Cc: GaretJax Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: yes
Easy pickings: no UI/UX: no


During the URL resolving process, the instance namespace is returned as part of the match object but then never propagated to the final view or made available to other middlewares (see

This value could be made available to the view as part of the request object (an attribute?) or another way which does not involve a second resolve call. It can then also be used as a default value for the 'current_app' argument of the 'render' shortcut or the RequestContext class.

Change History (7)

comment:1 Changed 7 years ago by GaretJax

Patch needs improvement: set
Triage Stage: UnreviewedDesign decision needed

I already create a PR for this (it got rejected as explained in but I can edit to comply with the requested points.

Before proceeding though, I'd like to discuss the addition of the 'current_app' attribute to the HttpRequest class. Someone sees a better way to design this?

comment:2 Changed 7 years ago by GaretJax

Needs documentation: set
Needs tests: set
Triage Stage: Design decision neededUnreviewed

Looking at how other solutions which add attributes to the Request instance resolved the problem, it seems like that the attribute should be set by the get_response method but without initialization in the HttpRequest constructor.

comment:3 Changed 7 years ago by Malcolm Tredinnick

Easy pickings: unset
Triage Stage: UnreviewedAccepted

Since the initial days of namespaces, this has been a "might be nice to have one day" kind of feature, so I'm not against the idea. The current patch -- ignoring any deficiencies -- looks like it's not going to be an incredibly intrusive change, either. So a good patch with tests would probably be worth committing for this.

I guess we need to work out what the exact format of the passed-through data is, but that's not going to change the implementation much. I'm currently updating the namespace documentation to ... well ... make sense, so this is going to come up more in the future as people start to use it.

comment:4 Changed 7 years ago by GaretJax

Cc: GaretJax added

Beside regrouping everything in a single commit, is there anything I can adapt in my proposal (

comment:5 Changed 7 years ago by GaretJax

Regarding the tests, there already is one checking for the presence of the attribute on the request instance. I can add one to check for the correct behavior of the render shortcut. Is there anything else?

comment:6 Changed 7 years ago by Luke Plant

Isn't this superseded by #15695 ? The ResolverMatch object seems to have all the info you want, from a quick look.

comment:7 Changed 6 years ago by Luke Plant

Resolution: fixed
Status: newclosed

Given no response, I'm closing as 'fixed'. Please re-open if #15695 doesn't fix your problem.

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