On Jan 30, 7:20 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sat, Jan 29, 2011 at 8:55 PM, Jari Pennanen <jari.penna...@gmail.com> > wrote: > If an engineer came to their supervisor with a problem and said "I'm > going to fix this problem with a global variable", they would be > soundly beaten by any supervisor worth their salt. Somehow, because > the name has been changed to "threadlocal", global variables have > suddenly become acceptable. > > Every single problem associated with using global variables exists > with threadlocals -- and then a few more. They *can* be used > successfully. However, in almost every case, they can also be avoided > entirely with a good dose of rigorous engineering.
Without the globals: What are the chances to get the load of patches to Django which would be required to implement following: get_request_site_id(request) get_request_media_root(request) get_request_media_url(request) Even these would require big patches, and thats not going to happen, it literally takes *years* to get those interfaces to Django and make all the apps working with the above interfaces even though they are simple changes. On top of that there had to be at least a second auth backend method (if not altered completly see below): get_user_request(user_id, request=None) And replace the django.contrib.auth.get_user() backend get_user() call with get_user_request() ----- Altering the auth backend role. In fact I think this module level django.contrib.auth.get_user(), login() is currently wrong way to do things in the first place IMO, it cuts out the authentication backend all together. It would be simpler to imagine this login / get_user as following: - Saving the user to request.session (currently handled by the module level login(), and backend.authenticate()) - Loading user from request.session (requests after login) (currently handled by the module level get_user(), and backend.get_user()) There is no simple way one could define own behavior for this saving and loading the user to session in auth backends. That simply is odd to me. It sounds like the thing I would like to define myself. If there were a way to define saving and loading user one could do cool stuff like: 1. per site login system (saving site_id to session during saving and fetching it from session during loading) 2. during login caching of user permissions to session (no need to hit database after login for permissions!) One could define the saving and loading of user to session in authentication backend with simple methods like: authbackend.save(session, user) -> bool authbackend.load(session) -> user object Then: - django.contrib.auth.login would become the caller for backend.save(session, user) of course the login() could still use the backend_session_key and user_id there - django.contrib.auth.get_user would become the caller for backend.load(session) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
