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 WidgetsBrainStorming


Ignore:
Timestamp:
11/21/05 08:26:41 (9 years ago)
Author:
michele
Comment:

corrections

Legend:

Unmodified
Added
Removed
Modified
  • WidgetsBrainStorming

    v2 v3  
    8080But, how can we make customization as easy also for complex widgets that embeds others widgets? For example the Form widget? Any opinion? 
    8181 
    82 == Smart Widgets == 
     82== Smart Forms Widgets == 
    8383 
    84 What about a class of widget that knows about their validation state? 
    85  
    86 Imagine a Form widget that let's you do something like this (only a pseudo code to show the general concept): 
     84In my own visions a Form widget should let me do something along these lines (only a pseudo code to show the concept): 
    8785 
    8886{{{ 
    8987#!python 
    9088@turbogears.expose(template="...") 
    91 def index(self): 
     89def edit_contact(self): 
    9290    myform = TableForm(widgets=[ 
    9391                widgets.TextField("name"), 
     
    9795    return dict(form=myform) 
    9896 
    99 @turbogears.expose(input_form=myform) 
    100 def save(self, input_form): 
     97@turbogears.expose(template="...") 
     98def save(self, myform): 
    10199    if not input_form.valid: 
    102         return self.index() 
     100        raise cherrypy.HTTPRedirect(...) 
    103101    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] 
     102        contact = Contact.byContactId(...) 
     103        contact.name = myform.name 
     104        contact.address = myform.address 
     105        contact.age = myform.age 
     106        turbogears.flash("Changes saved!") 
     107        raise cherrypy.HTTPRedirect(...) 
    105108}}} 
    106109 
    107 This 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. 
     110This way you shouldn't need a special has_error variable, or the need to check against cherrypy.request.form_errors and to take values from  cherrypy.request.input_values. 
    108111 
    109 To me it seems just more natural. 
     112We should be able to access values from the form as normal class attributes, python properties should use to_python and from_python FormEncode methods to ensure attributes values are valid and accessible in a transparent way. 
    110113 
    111114== See also ==