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? Daniel _______________________________________________ Zope-CMF maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
