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

[Gary Poster]

Hello all.  I'm have some thoughts and plans about schema, widgets, and
forms that I'd like to share and get feedback on.  I'd like to do it
through the list and then put it up on the wiki as a proposal (as 
"Advanced Schema and Forms Usage" or some such).

There is a good chance that the getter and setter addition might happen
within a week or two.  The rest of the stuff might be for later, if
someone doesn't beat me to it, as in within a month or two.

A lot of these thoughts and notes are based on talks with Jim, Tres, and 
Casey.  I may have gotten some of them wrong: errors are mine.

General notes about schema, widgets and forms:

  - I need the core of this to be stable, with primarily only additions
    here on out.  I imagine other people might feel the same way.

  - The ideas of hooking things up to XForms etc. sound interesting, but
    I'd prefer this to be implemented as a compatibility layer; otherwise
    it introduces problems to the bullet point immediately above.
    Certainly An XForms mechanism could be implemented in addition to the
    current mechanism later.

Things to add to interfaces/schema/widgets/forms:

  - 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.

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

  - 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.

    * 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...

  - 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.

  - 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.

  - 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.

  - 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.

  - 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.

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

Other notes:

  - What does the subedit form stuff do?  The name sounds tantalizing.

That's it for now.  I'd love to get some feedback.

Thanks

Gary