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.
> 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.
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 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.
>
> 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.
>
> 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 = ...
???
Kevin
