thread.local usernames & business logic support

[anonymous]

In Java webapps it's very convenient to set the user object to a thread local variable. This is for situations where the authorisation rules apply at the data level, not the page/url level. The advantages of this approach in Java MVC applications are:

• Web layer Controller code making calls to business logic / Service layer methods doesn't need to pass user objects around all the time.
• Business logic code doesn't need to know anything about HttpRequests, providing clearer separation of concerns and easier testing.

I think Django is truly excellent, am I trying to convince my team to ditch acres of Java/Spring xml config files in favour of it. However, I see very little emphasis in the documentation or the application design on business logic / business rules (rules like "can a user from this organisation modify this data at this time under these conditions"). View methods deal with Http and with naming templates. That doesn't seem an appropriate place. Also, there is no dedicated section in the documentation to writing Views, which seems to imply they are meant to be pretty lightweight. Models fire off data access functions in a brilliantly automagical style, and it seems terrible to override all those methods. The best place I can find is the Middleware method:

interface: process_view(self, request, view_func, view_args, view_kwargs) 

However, this would lead to complexity or bloat - either running millions of rules for every request, or doing something complex like keying business rules of the view function.

So this is a feature suggestion for two things. Firstly, support for setting users as a thread.local variable. Secondly, clarifying where the business logic which needs this functionality should go.

[Malcolm Tredinnick]

You are probably better to bring this sort of thing up on the users list, since you are making a few assumptions that aren't necessarily valid and it would be easier to have a conversation on the mailing list than in track.

The short answers to your queries are:

1. threadlocal settings are already supported. See CookBookThreadlocalsAndUser (which shows up pretty early on a Google search for the same), and
2. writing views doesn't get any real documentation because views are normal Python functions that can do anything, so we can't realy document "how to do anything at all". They are a place to put some of your business logic (other places include the models and model managers, since "business logic" covers a lot of territory and depends on the design) because they are the interface between the various layers. Somewhat (but not exactly) like the controller layer in a strict MVC division.

I don't think there's anything to "fix" here, but if you'd like to propose a patch to the documentation, please reopen and attach it. Otherwise, I think you'll get good support for these sorts of queries from the mailing list.