[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