On Wed, 2006-09-20 at 12:18 -0700, PoBK wrote: > Hi, > > I've just spent the last few hours looking around Django site, and > google and the mailing lists for any hints on the following problem. > > I need to implement functionality similar to that of the > django.contrib.sites module, the difference being that value of what > would be the SITE_ID setting, needs to be obtained from the current > session. > > The basic idea is that I would like to automatically filter model > results based on the contents of a list of elements in the request > variable. Lets for the purposes of this discussion, call it a > Container. > > So person browses site, gets assigned a blank list of containers. > During login the users list of containers gets populated. In terms of > the existing sites module, this step is the equivalent of setting > SITE_ID to a list of IDs (yes I'm aware that it would make no sense to > do so, but I'm saying this in terms of logic, not semantics). Any > requests for model data then that the user needs to modify or view then > gets filtered based on the values of this list of containers. > > I'm kind of a newbie to Django. Am I right in thinking the best way to > accomplish this if it is possible is by using a combination of model > managers and middleware? Is it at all possible to get any data provided > by middleware into the managers or are the managers one way elements?
You seem to have a pretty good grasp of what you want to do and how the logic flow will work. The approach you have outlined is certainly workable. The main thing you have to work out is how to pass the necessary parameters from the user's session (essentially) to the model manager without doing lots of repetitive or error-prone work. Models (and their managers) deliberately do not have any connection to the concept of "current user" or "current view" or "current request context", since they are independent data holders that can also be used outside of views. The suggestion you have received for using some middleware to populate threadlocals tries to solve this problem by putting the session information into the variable scope of the model code when you call it (it appears as part of the thread's "global" variables -- although more typically, and not just in Python, called thread locals, because it's local to that particular thread -- so the model and manager code can access it). The drawback here is that it can restrict the way you can use that manager method outside of the normal request/view path: if you want to call it elsewhere, you need to put some of the parameters into the thread local and then call the manager. Leads to a "push these parameters onto the shelf over here and then call this method over here" sort of idiom and can look a bit strange. The threadlocal solution will work with mod_python: after all, mod_python is meant to give you a Python environment. If variable scoping didn't work correctly, it would have to be called mod_not_really_python. Some debugging I did with Ian Holsman, looking over some code he had written that used it heavily, a couple of months back convinced me that the threadlocal solution looked very robust. I don't (yet) use it myself for anything, but, for what it's worth, I would recommend it if it suited your purposes. One alternative is to have a method on your manager that does the initial filtering and takes a request object or user session object as a parameter. The drawback of this approach is that you have to remember to pass in that parameter all the time. There are possible other ways to do this as well, although none spring immediately to mind. You just need to decide which of the trade-offs is more acceptable to you. You need to do some work somewhere, obviously, and how you intend to use the model code in your application and how many places you call that manager method from will help you decide which trade-off will lead to less work. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
