On 11/2/05, gsteff <[EMAIL PROTECTED]> wrote: > > > 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.
While I do agree that avoiding two widgets with the same name is handy, I personally find it more natural to make an instance of a class when I want to actively use something than to define a new class. The advantage to using a list is that it's strictly ordered and Python provides built in mechanisms to work with it while preserving the order. Kevin
