Kevin Dangoor <[EMAIL PROTECTED]> writes: > It looks prettier, to be sure, and it may be possible to eliminate the > need to instantiate one of these style forms. The code to make this > work is definitely much less pleasant than the other style of code.
Too much that you'd avoid working with it or that you'd be discouraged to work with it? > We could prefix those things with tg_, but that's ugly. I agree it is ugly... Maybe using just "_" would be better but... > We could make a "widgetmeta" class that holds the widget metadata. > That solves part of the problem, but doesn't answer the question of > where to put the methods for the widget. Alternatively, we could put a > "fields" class to hold just your set of widgets: > > class MyForm(TableForm): > class fields: > name = TextField() > age = TextField(validators=Int()) > > The nice thing about this approach is that the fields are cleanly > namespaced *and* your form object can comfortably have whatever > methods it needs to have on it. ... this is much better. And has a precendent: SQLObject works like this with its sqlmeta class. Maybe adopting something like what it uses is more interesting so the the developer won't have to "change" his "mind" to work with SQLObject or using Widgets. > My preference actually remains the original form of this, where you > instantiate the form, passing in a list of widgets. It reduces a lot > of complexity (like the need for an inner class, for example). > > I took the class-style declaration patch because I recognize that this > was popular with many people back in November or whenever this > originally came up. We do need to decide on this, and I think my > preference is for a "fields" or "widgets" inner class to hold the > widgets apart from the form's attributes. > > Other opinions? If it is going to be the inverse of SQLObject -- widgets in the inner class instead of class metadata --, then I prefer 'fields'. It makes more sense. This approach is also interesting to reuse widgets. One can have a 'forms.py' file -- as we have 'model.py' -- and just import the desired forms / classes. But, if you really think you won't be "happy" working with the code to make it work, then it is better to keep just one option... -- Jorge Godoy <[EMAIL PROTECTED]>
