[TransWarp] peak.web.forms (was re: State of the Onion)

[Roché Compaan]

* Phillip J. Eby <pje at telecommunity.com> [2003-08-09 17:43]:
> >During our
> >discussion I thought that we don't really need "field" and that widgets
> >can do all that you propose a field should do. I am still not convinced
> >this is necessary separation, but I'll have to think about it some more.
> 
> Widgets shouldn't be mutable, but a widget class by itself will not contain 
> sufficient parameterization for its instances.  Therefore, there are two 
> different objects at runtime: an object that describes the fixed properties 
> of the widget, and one that describes its state with respect to its current 
> usage within the web hit.

Why can't widgets manage state or why must they be immutable? They are
not really loaded with services. In my mind they have to do very little:
render a value and *maybe* store a value. In fact why do they have to
keep any state at all - the values they need for rendering come from
either the request or an object.

> >In my experience its quite common to use the same form for both. The
> >form does not prescribe how the widgets should be rendered. In the case
> >of the add/edit form you can call widget.renderInput() or just
> >widget.render() and for the view you can call widget.renderView(). But I
> >also think it should be very easy to manipulate the widgets in the form,
> 
> It should certainly be easy to change their *state*, and perhaps to 
> manipulate the form instance.  But not the definition.  I really want a 
> clear separation of class/factory from instance, with the former remaining 
> essentially immutable.

Agreed.

> >precisely because there may be differences between "modes". Sometimes
> >you just want to remove widgets on the edit form that are visible on the
> >add form. If the differences are overwhelming then create another form.
> 
> I'd prefer the objects to control their own destinies here.  If there are 
> things that should be different, this should be specified by the form or 
> widget definitions, not by application code at runtime.

If it is allowed to manipulate a form instance then I see no problem
with adding a widget to or removing a widget from a form instance at
runtime. This would fall under changing their *state*, not?

I think I realise where we maybe misunderstanding each other.

In Formulator you don't really have a form definition, you construct it
at runtime. You create an instance of the class Form, and add fields to
it with calls to "add_field". So you don't create a class in python and
define widgets as attributes of that class and I presume this is what
you mean when you refer to the form definition? In Zope3, widgets are
attributes of a BrowserView instance and they are also setup at runtime.
I have up till know thought of the form widget framework along these
lines.

In PEAK however, I think we should code forms in python so that we can
visualise them in UML and that is probably the page you are on already.

I imagine you see an addForm as:

    class AddForm(Form):

        class Name(model.Attribute):
            referencedType = widget.TextWidget
            css_class = 'field_input'
            size = 20

        class Age(model.Attribute):
            referencedType = widget.TextWidget

and not as:

    addForm = Form()
    addForm.addWidget( TextWidget(size=20, css_class='field_input') )
    addForm.addWidget( TextWidget() )

I think I should just make a prototype so that we have something
concrete to work from. I find it difficult and frustrating to only talk
about this.

-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za