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 1 and Version 2 of WidgetsBrainStorming


Ignore:
Timestamp:
11/20/05 13:31:38 (9 years ago)
Author:
michele
Comment:

quick addition (hope is comprensible)

Legend:

Unmodified
Added
Removed
Modified
  • WidgetsBrainStorming

    v1 v2  
    5050 1. Providing a custom Kid template 
    5151 
    52 Customization should be an easy task and should happen inside our templates. 
     52Customization should be an easy task and should happen inside our templates (not the controller). 
     53 
    5354Widgets should use CSS class and selector to make it straigthforward. 
    5455 
     
    7980But, how can we make customization as easy also for complex widgets that embeds others widgets? For example the Form widget? Any opinion? 
    8081 
     82== Smart Widgets == 
     83 
     84What about a class of widget that knows about their validation state? 
     85 
     86Imagine a Form widget that let's you do something like this (only a pseudo code to show the general concept): 
     87 
     88{{{ 
     89#!python 
     90@turbogears.expose(template="...") 
     91def index(self): 
     92    myform = TableForm(widgets=[ 
     93                widgets.TextField("name"), 
     94                widgets.TextField("address"), 
     95                widgets.TextField("age", default=0, 
     96                                validator=validators.Int())])  
     97    return dict(form=myform) 
     98 
     99@turbogears.expose(input_form=myform) 
     100def save(self, input_form): 
     101    if not input_form.valid: 
     102        return self.index() 
     103    else: 
     104        [save in the db and takes parameters directly from the input_form (ex. input_form.name, input_form.address) not cherrypy.request.input_values] 
     105}}} 
     106 
     107This way you shouldn't need a special has_error variable and the need to check against cherrypy.request.form_errors and to take values from  cherrypy.request.input_values. 
     108 
     109To me it seems just more natural. 
     110 
    81111== See also == 
    82112 * [http://groups.google.com/group/turbogears/browse_frm/thread/e964d2a05feda72c/103105fae5f9c5ba Forms declarative style]