Code

Changes between Version 5 and Version 6 of ClassBasedViews


Ignore:
Timestamp:
10/01/10 12:53:00 (4 years ago)
Author:
carljm
Comment:

add a couple additional notes

Legend:

Unmodified
Added
Removed
Modified
  • ClassBasedViews

    v5 v6  
    3030==== Store state on request, not view ==== 
    3131 
    32 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. 
     32Pass 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.  
     33 
     34Document 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. 
    3335 
    3436Example usage and view would be the same as shown below in "__call__ and copy()". 
     
    3739 * Avoids messy and non-idiomatic hacks. 
    3840 * Avoids copying or creating new view instance on every request. 
     41 * 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. 
    3942 
    4043Arguments against: 
    41  * Leaves some room for people to shoot themselves in the foot. 
     44 * It's unusual to have a class where you can't store state on self. 
    4245 
    4346==== !__call!__() and copy() ==== 
     
    6265 
    6366Arguments against: 
    64  * 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. 
     67 * 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. 
     68 * 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). 
    6569 
    6670==== !__new!__() ====