Hi Martin!
Martin Aspeli wrote:
I had a browse through the code at
http://svn.zope.org/CMF/trunk/CMFCore/interfaces. This work is
interesting to me not at least because it will enable us to write
against CMF (and hopefully Plone soon) code using Z3 idioms (e.g.
accessing things through interfaces, making it possible to use adapters
etc.) I think the migration path here has to be to get all the
interfaces in place first, and then gradually refactor code to work
through these interfaces as necessary.
However, I notice that none of the manage_* methods are not there, and
that many things have accessors only. I haven't looked at it in the
detail, but I'm wondering what the policy is here. For things like setup
scripts or control panel views or whatnot, being able to mutate the
values in tools
(http://svn.zope.org/CMF/trunk/CMFCore/interfaces/_tools.py) and
elsewhere (e.g. just setting dumb properties) would seem a necessary of
the interface. Am I missing something?
Those interfaces are just a first step. The fact they exist doesn't mean
that all the z2 mess is cleaned up and all classes have now well defined
interfaces.
If you look e.g. at the adapters in CMFCore/exportimport you'll see they
are cheating a lot. Most of them use methods that are not part of the
interface they adapt. Surely that's not optimal.
Converting the interfaces to z3 interfaces I did follow this policy:
- All properties and methods including their signature have to exist in
the class. This has to be verified by verifyClass unit tests.
- The descriptions in the interfaces should be in sync with the actual
implementation.
- Not to add private methods has a higher priority than making the
interfaces complete. Adding methods to the interfaces implies a
commitment to maintain that API. We lose a lot of flexibility if we just
add all existing methods to the interfaces. An incomplete interface is
better than no interface.
- Everything should go into the right software layer. Interfaces like
IPropertyManager or IObjectManager should be maintained in the Zope core.
That means there is still a lot of work necessary to find out which
methods should become part of the API and which parts of the public API
should be deprecated, modified or made private. Not just in the CMF, but
also in Zope.
Cheers,
Yuppie
_______________________________________________
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
