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.



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to