Changes between Initial Version and Version 1 of Ticket #22203, comment 3
- Timestamp:
- May 20, 2014, 3:01:05 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #22203, comment 3
initial v1 1 1 Does "per thread" (per request/response cycle) count as "global" state? 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`. 2 2 3 Most notable 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 would consider the ability to set a `current app` and have other parts of the (Django or end-user) code get that current app, without having to pass an object as an argument every step of the way.3 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. 4 4 5 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 %}` will just work without generic app authors having to explicitly build in support for multiple instances of their app being deployed within a single project.5 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. 6 6 7 Of course, I am only suggesting that Django use the value from thread local storage as a default, that can always be explicitly overridden. This puts control over reversing namespaced apps where it belongs, with the project author. The generic app author doesn't know what projects will use their app, if multiple instances will be installed, or what namespace the project author will use to install the generic app into the project's root URLconf.7 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. 8 8 9 Is there another "per request/response cycle" mechanism where we can set and access variables when we can't easily pass them as arguments? 9 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. 10 11 Does anyone else think this would be a good idea, or does anyone have an alternative suggestion?