PS: more succinctly: status notifications can happen in many places and passing the session to all these places just for the status notification does not make the code any clearer. Thus, I just want to access the session as a global variable -- how can I do that?
On Wed, Aug 26, 2009 at 2:30 AM, Dennis Fogg <[email protected]> wrote: > I looked at my code based on your feedback. > In this particular case, the code that needs the request is doing status > notifications > http://blog.ianbicking.org/web-application-patterns-status-notification.html > and > it needs access to the session from the request object. > > You are correct in that what I really want is per thread architectural > hooks so I can store the request there. > Django does not provide these hooks (probably on purpose) so I'm > discouraged in using it. > > But, sessions are a part of the overall web architecture and therefore need > to be exposed. > Sessions act like per user dictionaries to store information that are > similar to global variables. > So, I'm wanting access to this architectural element from anywhere (instead > of through the request object). > For status notifications, it makes sense to add something to the > notification from places other than the view > (and not have to pass the request or session since it's really an exception > use case). > This seems like a reasonable use case and rationale for accessing the > session. > But the question is: how do I implement this in django (or, rather, will > closures in middleware work). > > > > > > On Wed, Aug 26, 2009 at 1:42 AM, Matthias Kestenholz < > [email protected]> wrote: > >> >> On Tue, Aug 25, 2009 at 7:32 PM, Dennis<[email protected]> wrote: >> > >> > I seem to need the Django HttpRequest object in functions that are >> > called by view functions. >> > I could pass the request, but I'm thinking of trying to create a >> > closure in middleware so that >> > I can access the request object (and maybe other objects) from >> > anywhere. >> > This seems like it's stretching the django architecture a bit -- not >> > sure if I do this or if I should do this. >> > I'm still new to python and django, so I thought I'd solicit advice >> > first. >> > >> > I'm thinking that the django middleware will access the request object >> > and create a closure. >> > I think I can use a classmethod for the closure so I can access it >> > from anywhere. >> > This will create a new object for every request -- I'm assuming that >> > it will not impact >> > performance but I'm not sure. >> > >> >> What you are describing is not really different from storing the >> request object in a thread local variable, which in turn does have the >> same problems as storing a variable globally. It makes it non-obvious >> what's going on, and the functions work differently depending on >> external factors instead of depending only on the arguments you pass. >> >> In other words, it is bad style, makes it harder to write tests and >> generally makes the code non-obvious. >> >> If you need the whole request object inside a function, pass it >> explicitly. If you only need aspects of the request (f.e. the current >> path), only pass in the current path. It seems like more work for now, >> but will lead to cleaner, better and more maintainable code in the >> future. >> >> Remember, "Explicit is better than implicit." >> >> >> Matthias >> >> >> >> -- >> FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/ >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
