[Zope-CMF] Re: Add forms and menus

[Martin Aspeli]

Robert Niederreiter <rnix at ...> writes:

> +/-
> i would provide a default add form anyway. consider how archetypes
> works.

Not necessarily an example to follow, though, is it. :)

> you never write an addform (especially because there are
> none :)). for most of the usecases default sequencial add forms fit
> quite fine. so for most usecases even the registration for the add form
> is lost code lines.

I'm not so sure about that, because ...
 
> to provide this, the CMFBaseAddForm simply has to provide one more
> property.
> 
> class CMFBaseAddForm(BrowserView):
> 
>     @property
>     def fields(self):
>         portal_types = getToolByName(self.context, 'portal_types')
>         fti = getattr(portal_types, self.portal_type)
>         return form.Fields(fti.schema)


Here you assumption is that that schema is saved on and returnable from the FTI.
This is a pretty fundamental change to the way CMF and CMF types work. First of
all, it requires that the FTI can know "the schema", which will probably mean
storing the dotted name of the schema somewhere or inferring it from something
else (a class, or the factory - the IFactory interface actually has some support
for this).

Now, I'm not actually against this. Dexterity works in this very manner (it has
a lookup_schema() method that works a bit like the schema property above, and
can source the schema from a number of different places including TTW-only
configuration, a filesystem file or a real filesystem interface via a dotted
name). If some of that could be pushed down to CMF, then of course that'd be
great - less code to be kept in Dexterity. But I'm not sure CMF wants to swallow
that much of an architectural change at this stage.

Also note that defaulting to form.Fields(fti.schema) is probably not enough.
Many forms, at least, will require custom widgets, and settings like groups and
so on. Dexterity has a way for the schema interface to give hints for how it
will be rendered (using tagged values) and a (fairly hairy) algorithm for
including them, but I won't actually recommend that pattern for general purpose
filesystem code (it's necessary for the case where you have pluggable UI that
source schema fields from multiple sources - again something that's probably not
in scope for base CMF).

If we want to be true to the tradition of Zope 3 and its simplified content
types metaphor, then  I think we should assume that a type consists of:

 - a class
 - a schema interface
 - an add form/view
 - an edit form/view

plus the FTI to install it into the CMF site. I wouldn't try to be too clever
and generalise away any of these.

Martin