Right now it seems that for a generic app to support the possibility of
being installed in a URLconf with a namespace, the app author will need to
take care to explicitly define a `current_app` for every call to
`reverse()`, `TemplateResponse`, `RequestContext`, `Context` and `{% url
%}`.
Django already adds a `ResolverMatch` object to every request. Shouldn't
Django just use this to get a default value for "current_app", whenever
users don't explicitly define one?
This should make it almost a non-issue to define the current app for every
case except explicit calls to `reverse()`, `Context` and templates that are
rendered without a `RequestContext` object (as none of these have access to
the request).
We could even get a sensible default in those cases as well by storing the
current app in thread local storage, and using that as a default in
`reverse()`.
I've made a ticket for this, but it was closed as wontfix because thread
local storage is global state and Django is at war with global state.
https://code.djangoproject.com/ticket/22203
As suggested, I'm bringing this to django-developers to ask for any
alternative suggestions that don't involve global state, and also to try
and make my case for the ticket as originally described.
Django already uses `threading.local()` in a number of places such as
`urlresolvers._prefixes`, `urlresolvers._urlconfs`, `CacheHandler._caches`,
`ConnectionHandler._connections`, `trans_real._active`, `timezone._active`.
The most notably similar use case is probably for timezone support, which
allows users to call `activate()` to tell Django what timezone they are in,
and then other parts of the code call `get_current_timezone()` to get the
value stored in thread local storage.
I think it would be along the same lines to have the ability to set a
current app and have other parts of the code get the current app, without
having to pass an object around as an argument every step of the way, which
is practically impossible.
For example, models with a `get_absolute_url` method (or perhaps multiple
`get_foo_url` methods) that are rendered in templates. These functions
can't take arguments when rendered as context variables in a template, and
have no way to obtain the current namespace from the `request` object.
This would make it super easy for users (via middleware) or Django itself
to inspect the `request.resolver_match` object and set the current app
early in the request/response cycle, and then `reverse()` and `{% url %}`
would just work without generic app authors having to explicitly build in
support for multiple instances of their app being deployed within a single
project.
Does anyone else think this would be a good idea, or does anyone have an
alternative suggestion?
Cheers.
Tai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/a7a8b2fb-91db-4b0a-ac1b-d76c5df38aa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
