Wow, are you mind reading?!
I was going to start a new discussion about this. :-)

Kevin Dangoor wrote:
> ...
>
> 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?
>

This is also my preference and the one who seems less obtrusive, I
would vote for the fields name since it's self explanatory (also see
point -2- below).

Anyway this should be fixed in one way or another, I can't test this
(as I'm unable to checkout cherrypy :-() but, for example, last time
I've tried you can't subclass a widget and override the template ATM.

Here are two other things I was going to write about in my email:

-1-

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.

(This thing was more related )

-2-

I my vision of a CompoundWidget I think it would be nice to standardize
the place where a widget of that type collects it's child widgets.

For example the actual Form widget uses:

widgets = []
submit = SubmitButton()

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.

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.

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. :-)

Ciao
Michele

Reply via email to