Dieter Maurer wrote:
Martin Aspeli wrote at 2007-4-15 16:45 +0100:
Aesthetics were not the original reason for moving down this route, so it's a little unfair to cast it in that light. The main drivers, as I recall, were to encourage API usage that would allow us to move tools out of content space eventually

Probably, I do not understand "content space". At least, I do not
understand why you want to get tools out of it.

If the root of your CMF/Plone site contains content items, they need to avoid collision with magical objects that are there primarily to make our lives easier as programmers (since you can acquire them, and they interact with Zope security easily, and they give a somewhat simple place to hook configuration UI into, and they give a somewhat simple place to stick configuration data).

Most CMF tools are location specific configurations (catalog, skins,
actions, types, ...) with a bit of functionality.
I do not see a big gain in implementing
them as local utilities rather than their current implementation.

I'd like them not to be there as attributes/keys/ids of the portal. In Zope 3, this is solved by using namespace traversal adapters giving access to persistent components only under a special namespace (++etc++site).

and to make code depending on CMF tools more consistent with "newer" code which may depend on new utilities (at least in the Plone world, there is a general consensus that we'd rather not have any more content-space tools from now on).

Hm: is their really that big a difference to call "getToolByName"
or "getUtility"?

Not me, I already know what all the tools are. It is a pain to the new developer who has to learn that things which are conceptually quite similar are accessed in an "old" and a "new" way, depending on whether they were written before some watershed when most people decided to switch to using utilities and views.


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to