[Zope3-dev] Thoughts and proposals re: Schemas, Widgets, and Forms

[Florent Guillaume]

We're doing a comparable framework for CPS (for Zope 2), and the
resemblances are uncanny...

Of course this framework is heavily inspired from Zope 3 concepts so
this isn't very surprising. Note, when I'm saying "schema" below, it's
not really a Zope 3 schema, but has the same goals and concepts (fields,
constraints, etc.). Our implementation keeps to the CMF philosophy. It's
not finished BTW :)

>   - interface-level constraints and validation.
> 
>     * Use cases: start date should be earlier than stop date.  Other
>       ordered examples where the constraint applies to more than one
>       field.  Currently this can be accomplished by constraining one or
>       both (or all) of the fields, both of which have drawbacks.

We're handling this by giving a global validation to the schema itself,
that has to be checked after a field has been changed. This may raise
errors too. The global validation can implement arbitrary constraints
and recomputation of invariants.

>     * This needs to allow for associating errors with fields, but not
>       require it.

Our errors are not associated with the field but with the validation
process itself. There may be different errors. The possible errors for a
field are not introspectable though (we have no need for that).

>   - forms should allow entry of multiple schemas, i.e. a content object's
>     base schema as well as adapted, annotated schemas.
>
>     * use cases include document objects, with a very simple schema,
>       needing to also include data entry or edit for Dublin Core and
>       perhaps another annotated, adapted data set.

We have a notion comparable to that, an object's data model can be based
on multiple schemas. A common Dublin Core is the obvious use case.

>     * back end implementation might be subclassing of multiple schemas.
>       If accomplishing this is only doable with explicit subclassing to
>       define a single new schema, Tres regards this as a hack, but he
>       might be willing to accept this as a hidden backend mechanism.
>       However, the simple-minded approach to this solution would not
>       allow an object to have the same attribute name in the separate
>       schemas: the base class schema *and* the Dublin Core could not
>       both have a "title" field defined using a simple-minded solution...

We have that constraint too.

>   - form mechanisms should more gracefully use adapters to allow for edit
>     forms based on adapted schemas.  For instance, a document object that
>     is adaptable to a DublinCore interface should be able to use the
>     DublinCore form.  Now it does part of the right thing, but the
>     adapted object must be the view context, which, perhaps among other
>     things, breaks breadcrumbs.

We can have assign a view for each subschema, and reuse it in the
definition of the view for the global schema of the object. I'm not sure
how generic I'll make it.

>   - edit forms should be able to show readonly widgets for fields that
>     cannot be edited but can be viewed by the current user, and
>     *perhaps* should be able to hide fields that cannot be viewed by the
>     current user in edit and view forms.

This is a very important use case for us. Each field specifies when it
is readonly, and when it is visible. I think we'll use TALES or a
simplified role or workflow condition for it (à la DCWorkflow guards).

>   - the use case of an object that changes field states--from editable
>     to published (or "frozen" or "cooked")--on the basis of workflow
>     needs to be addressed.  This could be solved without changes to the
>     current framework by switching schemas on the basis of the state.
>     This pattern may deserve discussion as a solution.

Exactly, the editable/visible in our case is very often based on
workflow constraints.

>   - schema currently is a way to specify attributes and properties.  It
>     could also be used to specify pairs of getter and setter methods that
>     have the same behavior as a property made of those getters and
>     setters.  This would be a nice, simple addition to the capabilities
>     of schema that follows similar ideas in other frameworks (or so I am
>     told :-) and coincidentally would allow schema to be used in Zope 2.

We don't have exactly that, but on the other hand the way the data
corresponding to a given subschema is retrieved from or set into the
object is handled through an intermediary which we dubbed Adapter :-)
which can decide to get/set the values as attributes, or put them in a
big dict, or use an SQL connection, or whatever. Zope 3 already has
adapters so it's easier there.

>   - Other emails have already discussed a need to group fields.  I sent
>     a separate email discussing some of my opinions on that.  I read
>     that Steve and some other folks have specific proposals about this
>     so I'll leave this alone for now, except to say that I'm very
>     interested in it, and to say that I'd like to be able to have the
>     templates be able to specify groups through which they can cycle, to
>     place different field groups in different (i.e., not necessarily
>     consecutive) places on the page.

Here I'm not sure what we'll do. In any case this will be delagated to a
Layout component.

>   - errors should be clearly associatable with widgets for display per
>     widget, if so desired (this may already be the case?)

Yes, cleanly placed error messages is also a very important use case for
us.

Florent


-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com