Robert Niederreiter <[EMAIL PROTECTED]> 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 _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests