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

[Tim Hoffman]

Hi



On Thu, 2003-04-03 at 18:49, Florent Guillaume wrote:
> We're doing a comparable framework for CPS (for Zope 2), and the
> resemblances are uncanny...

Me too. I have constantly found that existing tools and approaches
for auto forms/views is just too labour intensive. My plans mirror=20
almost everything here (including field level view control)

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

My plan to address this, is by having sub forms. These are either=20
rendered inline as a group or as a popup to deal with more complicated
widget/behaviour.

Here are some chicken scratching notes on what I am doing (it is about
half done)

Form Management
Portal Forms Tool.

Inside the Portal Forms tool there are a number of Formulator Form
instances and Form definitions.

To get a form call
context.portal_forms.getFormByType(context.Type()).view_edit(context,REQUES=
T) or  context.portal_forms.getFormByTpe(context.Type()).view(context)To re=
nder you can then either call view or edit.   Types tool view and edit meth=
ods would map to these.  Alternately you can request a specific form direct=
ly and then pass an object to be edited to it.=20

form =3D context.portal_forms.getFormByName('my_edit_form')
form.view_edit(context,REQUEST)

A =93Form Definition=94 this comprises of=20

- 1 or more references Formulator forms (these are used as field
definition repositories) (required) The same formulator can be used in
multiple forms.

  - 1 or more pages/forms (as in multi-page forms) (required).=20
    The pages definitions are ordered. (this determines page/tab order)=20
    Each page is made up of a single layout table (next button will =20
    validate and save values to session object. On the last page =93Save=94=
=20
    button is used instead. This will validate and write to session=20
    object and then call save method.

   - Page
    Each cell in the page defines a span, a field reference if=20
    appropriate and a span and a field use, properties for each=20
    cell are (possible class/formatting as well ??)

    - Cell
      Field reference (if defined must exist in one of the defined=20
      Formulator Forms. Or must be a another form or (template or=20
      script   )=20
     =20
      A Field use can be

        Field Use

          label,=20

          field value,=20

          sub form- If use is sub form-???? then alternate_render as=20
          defined in the field indicated by the field reference. Sub=20
          form types are=20
          sub form inline

          sub form popup

          colspan (how many cells does this field span)

          rowspan (how many cells does this field span)

          Page ?? edit permission (to short circuit if no field would=20
          appear if field permissions would disallow whole page anyway)

          Page ?? view permission. (As with Page edit permission)

    Page level validation method this will be used to validate a group=20
    of fields together logically beyond individual validation. You=20
    might then group logically related fields on  a single page.

A save method definition (optional) if no save method provided then this
must be a sub form either in-line or popup so it would only write into=20

Total form view method (optional) this is used to override the default
view method in the case of multiple page forms so that all data can be
put on a single page for viewing.

View after save method. This is called after final save, if not defined
then give default view method for this object. (Portal Types view
action)

Page Display properties

  Display multi forms as tabs boolean (you would normally have auto=20
  view with tabs)

  Enable help popups (description text of field)

Session prefix. (This is used because all forms write to a session
object before final saving, each form has form level validation) The
same user is editing multiple records simultaneously as a Unique edit
session using the prefix is started for each start of edit.
Portal type =96 This is the portal type that the form is related too. Call
portal_forms.getForm(context.Type()) to get the form for this object. In
theory the Type Tool edit action should do the same. (This needs a new
cut of CMF (I understand a branch by tres seaver has the updated
ActionsTool Actions code in TypesTool.). In the meantime you would just
put a wrapper script called some generic name and it would grab the form
and then call it.) Actually you will always need to do this otherwise
you can't pass the object to be edit to the form.


Formulator Modifications
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Formulator Field definitions need the following additional attributes
alternate_render =96 method that can be called to override render for the
field
view_permission (returns true when called for view)
edit_permission (returns true when called if can be edited)
Description field is used as help text.

Issues=20
=3D=3D=3D=3D=3D=3D

write back to parent form (session and screen) on sub form popup close
(ie refresh or DHTML). How to generalise this.


Tim