> Isn't that just begging to be... > class myform(TableForm): > name = widgets.TextField() > address = widgets.TextField() > age = widgets.TextField(default=0, validator=validators.Int())
Well, it depends on whether you think the name of the field in the form belongs to the field or the form. I've implemented basic form generation toolkits both ways, and generally think its cleaner to make it belong to the form as above (since that reinforces the idea that no two fields can have the same name), but there are reasons to make it belong to the field too... for example, turbogears.forms currently uses the name to create a default label if no other label is provided. Obviously, you can accomplish whatever you want either way, its just a question of which is more natural. I actually like the idea of making the name belong to the form, but using the dict style interface ( form['name'] = widgets.TextField() ). Unfortunately, this makes it more awkward to make widgets themselves part of the form definition, since elements, unlike attributes, aren't part of class definitions (am I using the right terminology here?). But I agree that the "widgets=[...]" syntax isn't the most natural, though I don't know what other tradeoffs might have been involved in choosing it. Greg
