Changes between Version 5 and Version 6 of ClassBasedViews

Timestamp:

Oct 1, 2010, 2:53:00 PM (14 years ago)

Author:

Carl Meyer

Comment:

add a couple additional notes

ClassBasedViews

@@ -30 +30 @@
 ==== Store state on request, not view ====
 
-Pass around the request object via method arguments, store arbitrary state on the request (perhaps in a blessed dictionary for that, or just in attributes). Document that state should be stored on the request, storing it on the view instance is unsafe, just like is already the case with ModelAdmin subclasses.
+Pass around the request object via method arguments, store arbitrary state on the request or a special "state" object or dict that is passed around or attached to the request. 
+
+Document that state should be stored on the request, storing it on the view instance is unsafe. Additionally, override __setattr__ or __setattribute__ to make setting state on self raise an error or warning.
 
 Example usage and view would be the same as shown below in "__call__ and copy()".
@@ -37 +39 @@
  * Avoids messy and non-idiomatic hacks.
  * Avoids copying or creating new view instance on every request.
+ * All the options for actually protecting against thread-unsafety involve some kind of "surprising" behavior. The surprising behavior here (can't store state on self) is explicit and fails immediately, rather than failing mysteriously and only under concurrency.
 
 Arguments against:
- * Leaves some room for people to shoot themselves in the foot.
+ * It's unusual to have a class where you can't store state on self.
 
 ==== !__call!__() and copy() ====
@@ -62 +65 @@
 
 Arguments against:
- * The "copy on !__call!__()" approach is a little messy. Normal Python idiom wouldn't lead users to expect that !__call!__() would cause a copy to be created. However, this is entirely hidden by the implementation.
+ * The "copy on !__call!__()" approach is a little messy. Normal Python idiom wouldn't lead users to expect that !__call!__() would cause a copy to be created.
+ * The abstraction of the copy-on-call can leak in surprising ways. Some users will try to set up state using an __init__ method (common practice). If any of the state they attach to self in __init__ is mutable (list, dict, etc) and they mutate it in the view, this is once again un-threadsafe (but will appear to work fine locally).
 
 ==== !__new!__() ====