Kevin Dangoor wrote: > On 1/19/06, Michele Cella <[EMAIL PROTECTED]> wrote: > > Is there a way to make the widget instance a callable that defaults to > > the insert() method? > > > > Example: > > > > instead of: > > > > form.insert(action...) > > > > it would be nice to use (at least for me): > > > > form(action...) > > > > since the insert() method is the most used inside a template this could > > be convenient. > > We could do this. I can't think of any drawbacks offhand.
Great. > > > > what about making widgets a dictionary? for the Form: > > > > widgets['fields'] = [] > > widgets['submit'] = [SubmitButton] > > > > this should make it clear to thirdparty widgets writers where they > > should put child widgets, and it feels more natural to me since child > > widgets are clearly categorized. > > The submit button is the only one that is special, and the only thing > that's special about it is that it's value is pulled out of the input > if it shows up there. (I guess it's also special because it's > automatically created for you). That's not the case anymore: http://trac.turbogears.org/turbogears/changeset/528 I also think that as errors should be displayed by the container form (#125), this also applies to a widget label, this means we should remove the label attribute from a simple Widget (like a TextField) and rename labeltext to label. TextField(name="age", label="Enter your age:") now the form will simply use it's label widget (in my vision widgets['label'] = Label()) to insert the proper label. > > That's where there's the widgets list and the submit button and that's > it. I can't think of a reason, offhand, why we'd need other > "categories" of widgets to appear. as said above: Label for a Form. :-) And maybe others would need them. > > > > > It's also easier if you need to dig into a widget you know you can > > refer to the widgets attribute for customizing it's behavior. > > I do agree that having a standard interface for this is good. Yes, and in particular this is essential if we want (and we want it) a CompoundWidget, if we don't know where attributes containing widgets would pop-up we can't provide a ready-to implementation of retrieve_css and retrieve_javascript and every widget writer will need to override it if they are putting other widgets outside of the widgets attribute. If we know and suggest that you put all your widgets there, the retrieve_js and retrieve_css method just need to iterate over the widgets dict and over every key to to do the same thing without further modifications. To me it just seems as good practise (from an OOP POV) grouping together those related component (Widgets). Moreover given that widgets are state-less and you wouldn't need to access them too frequently moving them here will not hurt anyone I think, and will establish a good conventions for the future. I finally think for a form we should use: Form(fields=...) and not: Form(widgets=...) > > > > > Maybe if we abstract the declarative mechanism to a CompoundWidget we > > can provide facilities like this for every CompoundWidget: > > > > class Test(TestCompoundWidget): > > class foo: -> widgets['foo'] = ... > > ... > > class bar: -> widgets['bar'] = ... > > ... > > > > Ok, enough crack for the moment, excuse me. :-) > > wouldn't that be: > > class Test(...): > class fields: > foo = ... > > ??? > Mmm, sorry I was already using my own widgets convention, so foo and bar are categories. But anyway that's not a problem anymore. Ciao Michele
