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 < matthias.kestenh...@gmail.com> wrote: > > On Tue, Aug 25, 2009 at 7:32 PM, Dennis<dennisf...@gmail.com> 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 django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
