Am Mittwoch, den 16.07.2008, 16:24 +0200 schrieb Daniel Nouri:
> 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?
in the case where ICMFAddForm is no longer my interface to look up. then
i have to overwrite the traverser.
> Zope-CMF maillist - Zope-CMF@lists.zope.org
> See http://collector.zope.org/CMF for bug reports and feature requests
IT-Architecture & Engineering
+43 699 160 20 192
+43 512 89 00 77
Squarewave Computing WEB APPLICATIONS, ZOPE, PLONE, HOSTING
BlueDynamics Alliance production: concept, development, design
http://squarewave.at consulting: analysis, coaching, training
http://bluedynamics.com management: projects, process, community
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests