On Mon, Jul 20, 2009 at 9:26 AM, Bartłomiej Górny<bar...@gorny.edu.pl> wrote: > [...] >> there is a cookbook recipe for achieving this sort of thing: >> >> http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser > > Yep, that's exactly what I did :) > >> >> That's deep in the category of 'give them rope to hang themselves >> with' though. You should understand the implications and design >> decisions involved before hacking your way around it. > > I give +1 to Joshua's request - plz explain. >
thread locals have all the problems which are generally associated with global variables. They might be overwritten by other code, they make testing extremely difficult because the behavior of methods may depend on non-obvious circumstances and it's not clear from the method signatures which variables are really used -- in short, it makes code maintenance much harder than it needs to be. I'll try giving a few examples: - You have a field on your model called last_modified_by, and you automatically assign request.user in the save() method. You made this piece of code much harder to test in an unittest than it needs to be, because now you have to provide the complete environment including the variables from the threadlocals space in your testsuite. More code is needed, and the probability that the code and the testsuite (and eventual documentation) get out of sync gets bigger and bigger. - Something which I've done for a CRM system which we've developped for internal use together with another company was giving Tasks access levels, so that we were able to make certain tasks viewable only by the management. I built a manager which uses the user information from thread local space to filter the queryset automatically according to the profile of the currently authenticated user. With this seemingly simple move I've made it impossible to use loaddata/dumpdata, because no user exists, and I made it very non-obvious that the list of viewable tasks depends on the user. You would not get the idea that filtering is going on in the templates or even in a big part of the code. This is not a big problem when developping alone, but it can really hamper progress if someone else takes over the codebase. In short: It's easy and it gets the job done, but will come back and bite you later for sure. Don't give in to the temptation -- it's much better to write custom template tags where you can pass the user explicitly to the function, which makes it very clear that the output/the result of a certain function depends on the user. It also makes testing a breeze, because the behavior of methods is only determined by their arguments (as it should be), not by other circumstances or the current weather. Matthias --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
