On Friday 03 October 2003 08:57, Mark Bucciarelli wrote:
> I would probably start with a login widget, which would require an url as
> an __init__ parameter.  The widgets default behavior is to require both
> fields. If you add that widget to your Quixote form, and someone clicks the
> login button, the process() and action() methods (of an enhanced form
> class) will trigger this widgets process() and action() methods; that is,
> if both fields are not entered, then display a hint and re-render the form.
>  Otherwise, load the user/pass into the session object, and go to the url
> specified in the init.
>
> This is a trivial example because it doesn't save _that much_ time, but
> hopefully it's a bit clearer explanation of my idea.
>

Yes, it clarifies it to me a lot and I'll tell you that I find your vision of
a form as a widget inside another form really profitable.
But some questions still arise to me. I'lll show you some:

This 'enhanced' form class,  act as a real form, just a form container or
both?

What kind of interaction between the widget forms and the container, would be
supported? I mean, can a form's action create, delete, or maybe disable,
enable or hidden other forms?

Should container form's action() method be notified of submissions on any
widget form? Could a submission be notified to  all action methods? or could
a widget form transfer his action method to container's method?

I'm just trying to center the discussion.

Òscar Rambla

Records, (Regards)