[Zope3-dev] Schema, widget and form refactoring (was Re: [Zope3-checkins] CVS:Zope3/src/zope/schema - _bootstrapfields.py:1.19.2.1)

Steve Alexander steve@z3u.com
Tue, 22 Jul 2003 22:29:28 +0300


> If you want to remove something from widgets, make it the label() and
> row() methods.  And the things Jim's marked as deprecated (render(),
> hidden()).

I'd be in favour of this. There are many conventions for what makes a 
row in different web applications. Some people might even want to use 
table cells to lay out their forms.

The label and row metheods should belong to an interface of a component 
that lays out a widget in a form. They shouldn't be part of a widget.


>  > This distinction arises in the fact that *all* of the widgets are
>  > populated in preparation for the form submit processing, even those
>  > widgets that don't have data in the form.
> 
> I'll think about this some more.  It's good that you're questioning
> the assumptions, but it's not clear to me that this particular aspect
> is getting anywhere.

I don't think so. The idea is that you can specify not an entire schema, 
but just a list of fields for layout in a form.
When we implement cross-field constraints and schema-level validation, 
we'll still want to know what the schema is.
But, I think your use-cases are taken care of if you can supply a list 
of the fields from within a schema that you should use.

Marius and I worked on a proposal (still not yet published, but 
discussed with Jim at the Bristol Sprint) to have a presentation level 
abstraction of Field Collections separate from schemas for representing 
a collection of fields that may be a subset of the fields from one 
schema, or a mixture of fields from many schemas. Yes, I'm using 
something like this in an application already. I think Marius is too.

Both Marius and I are really busy right now, so I guess we'll wait a 
while before doing anything about this.

--
Steve Alexander