[Zope-CMF] Re: Add forms and menus

[Robert Niederreiter]

Am Mittwoch, den 16.07.2008, 13:04 +0000 schrieb 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.
it's not that big architectual change. everything else discussed is
possible anyway. i would rather call it a feature than a design change
(since the change happens anyway).

we discuss the generic adding approach, we further discuss what has to
be considered to be generic.

2 more properties on the fti (addforminterface, schemainterface), both
are optional, but provide then the discussed and requested flexibility
for different type implementations.

if we do not consider this questions at this state, again the result
will be stupid and ugly subclassing and incompatibility and bad readable
code and overrides.zcml (which is one thing i really hate!).

> 
> 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).
right, therefor you always have the possibility to write your own form
implementation.

> 
> 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.
i don't try to generalize, i try to simplify. and i think such default
behaviour is benefit in any way.

i simply wonder why people should write code for default behaviour when
there can be a default implementation.

i only want to point here to the plone portlets engine. why is it
necessary to provide 4 (!) classes, a template and a zcml configuration
for 1 portlet? thats imo too much, especially because people are
familiar with and love the 'write-less-do-more' mentality, and adherence
to a tradition is not automatically more productive or easier to
understand.

Robert

> 
> Martin
> 
> 
> 
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF at lists.zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
> 
> See http://collector.zope.org/CMF for bug reports and feature requests