Tres Seaver wrote:
> Jean-Marc Orliaguet wrote:
> >Julien fixed a bug. Only poorly designed software implements hardcoded
> >references to paths ('portal_catalog'). And he needed it to implement a
> >separate catalog for portlets. So let's move on....
> 'portal_catalog' is not a hard-coded reference to a path; it is a
> "well-known name" for a service, which in the original design is a
> singleton. As a parallel, think of the interface or the name used to
> find an adapter in the Zope3 component architecture; code which uses
> them is equally "hard-wired".
> The point of the 'getToolByName' indirection was to mark such uses as
> intended service lookups. Code which blindly uses direct attribute
> lookup, e.g. 'context.portal_catalog', *is* buggy.
> Julien's refactoring is not a bugfix, but a refactoring, intended to
> allow the possibility of using more than one catalog. I would actually
> prefer to see it spelled as an adapter lookup, in the CMF 2.0 world, so
> that we don't implement yet another component architecture. The
> refactoring as written is fine for the 1.5 branch, however.
the "buggy-ness" then lies in the fact that portal_catalog provides both
catalog functionality and catalog content. In comparison 'portal_skins'
at least puts the skins in sub-folders, thus doing a separation between
functionality and content. Maybe this is where the problem lies.
Then of course the equivalent of a named zapi.getUtility(ITool, name)
for zope2 would be great. But it is not there yet. getToolByName()
provides an indirection on the tool interface but not an indirection for
a named tool.
So I don't think that Julien's fix is perfect but pragmatically speaking
(until a complete refactoring of CMF's getToolByName() is done) how
would you have done otherwise to get a dedicated catalog in CMF 1.5?
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests