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
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"
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 - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests