Robert Niederreiter writes:
> 2 more properties on the fti (addforminterface, schemainterface), both
> are optional, but provide then the discussed and requested flexibility
> for different type implementations.
If you copy a FTI, you can probably reuse the add and edit forms
available for the type you're copying.
If you're using a different schema, you'll write filesystem code anyway.
In which case it's easy enough to register another add and edit form.
This will also avoid redundancy with the proposed addforminterface and
schemainterface FTI properties in the case of custom add and edit forms.
And it'll make it obvious to the developer where to hook in to customize
the default forms.
> 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!).
As soon as whatever default form that's provided by the framework
doesn't work for you, you're back to "stupid and ugly subclassing",
which I don't think has to be stupid and ugly at all. In fact, I
believe that using subclassing or utility functions in these forms will
lead to more understandable code here.
Where would we need overrides.zcml?
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests