Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Changes between Version 2 and Version 3 of StatelessWidgets


Ignore:
Timestamp:
04/26/06 14:07:50 (13 years ago)
Author:
anonymous
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • StatelessWidgets

    v2 v3  
    6262}}} 
    6363 
    64 == 2) Changing widget instance's attributes inside a request it's not threadsafe == 
     64== 2) Treat widget instances as immutable after creation == 
    6565 
    6666Since the same widget instance is used across all requests its instance 
    6767attributes should be immutable so that any thread has a consistent view 
    68 of the instance. 
     68of the instance. In particular, changing widget instance's attributes  
     69inside a request is not threadsafe. 
    6970 
    7071'''Yes:''' 
     
    115116}}} 
    116117 
    117 Whenever you see "self." somewhere other than the constructor, you know  
     118Whenever you see "self.<attribute> = <value>" in a widget class outside its constructor, you know  
    118119you're in trouble. If two requests come in simultaneously and both try to  
    119120render that widget at the same time, the two users might end up getting  
     
    125126to request? 
    126127 
    127 The attributes that define the substantial knowledge and behavior of a widget  
    128 are sent in via the constructor while the parameters that can change from  
    129 request to request are sent in at render time. 
     128 1. Define the widget's ''request-independent'' knowledge and behavior at construction time. 
     129 2. Define the widget's ''per-request'' knowledge and behavior at render time. 
    130130 
    131 In substance you can resemble a widget to be like a controller's method, the  
    132 widget appearance is defined by its template attribute and at render time you  
    133 send to its template (display() or render() methods) a set of parameters that  
    134 are request dependant and that the widget manipulates (update_data() method)  
     131In this sense, a widget is similar to a controller's method: the  
     132widget appearance is defined by its template attribute, and at render time you  
     133send to its template (via its display() or render() methods) a set of parameters that  
     134are request-dependent and that the widget manipulates (using its update_data() method)  
    135135to behave correctly. 
    136136 
    137137Although the widget/controller's method parallelism can help to understand  
    138 how a widget works it's important to underline that unlike a controller's  
    139 method a widget is not responsible of directly responding to a given request, 
    140 this job is always left to the controller method that takes care of  
    141 interacting with the widget and sending request dependant parameters to it. 
     138how a widget works, it's important to remember that unlike a controller's  
     139method a widget is not responsible for directly responding to a given request. 
     140This job is always left to the controller method that interacts with the widget  
     141and sends request-dependent parameters to it. 
    142142 
    143143{{{ 
     
    160160==== References ==== 
    161161 
    162 This document also takes inspiration from some discussion that have take place 
    163 in the google group (for example Bob Ippolito's reply [2] that clearly tells  
     162This document also takes inspiration from some discussions that have take place 
     163in the Google group (for example Bob Ippolito's reply [2] that clearly tells  
    164164why you shouldn't change an instance attribute inside a request, and some replies  
    165165by Kevin).