Re: Closures, Django Request Object, Django architecture
On Tue, Aug 25, 2009 at 8:35 PM, Dennis Fogg wrote: > 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? > Sending messages to an user is very much tied to the current request -- only the current request can tell you which user is active currently, so whatever way you choose to store and retrieve notifications (database, sessions etc) you always need the request object in one way or the other. Really, there is a reason why Django does not provide global (or thread local) request / user objects. If you still want do do it, google for "threadlocals user", but I'd advise against doing that. In the end, it's your decision though. Btw, I've used this thread locals hack in the past, and it served me well for some time. It came back to bite me though, and I wish I hadn't used it; it really makes writing a testsuite a pain; dumpdata does not work because the manager of a single model depends on a thread local request object with an authenticated user etc. It's much better to cope with the need of having to pass the request around than pick up the pieces afterwards when choosing the simple path now. 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 -~--~~~~--~~--~--~---
Re: Closures, Django Request Object, Django architecture
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 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 < > matthias.kestenh...@gmail.com> wrote: > >> >> On Tue, Aug 25, 2009 at 7:32 PM, Dennis 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 -~--~~~~--~~--~--~---
Re: Closures, Django Request Object, Django architecture
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 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 -~--~~~~--~~--~--~---
Re: Closures, Django Request Object, Django architecture
On Tue, Aug 25, 2009 at 7:32 PM, Dennis 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 -~--~~~~--~~--~--~---
