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.
> Tres.
> --

Hi Tres,
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  -

See for bug reports and feature requests

Reply via email to