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.

> Daniel
> _______________________________________________
> Zope-CMF maillist  -
> See for bug reports and feature requests
Robert Niederreiter
IT-Architecture & Engineering
Aflingerstraße 7
A-6176 Völs
+43 699 160 20 192
+43 512 89 00 77

Squarewave Computing         WEB APPLICATIONS,  ZOPE,  PLONE, HOSTING
BlueDynamics Alliance        production: concept, development, design         consulting: analysis, coaching, training      management: projects, process, community

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to