Chris Withers wrote:
Hmm, okay, how have the UI's for the creation of local utilities been
built? (I'm thinking there must be some kind of drop-down somewhere
with an "Add list" as in Zope 2's ZMI, and that must include the
available types of local utility?)
Sure. Just use the standard "Add" menu in Zope 3. Some of the items
there are potential local utilities, such as the Catalog, Cookie
Client Id Manager, Error Logging Utiltiy, etc. You can add these
objects anywhere, though it is recommended to do it within
++etc++site. The thing that makes them available as utilities is the
registration. All objects have a "Registration" tab.
Ah, I see, so rather than using ZCML, you use the Registrations tab?
(now I'm dying to know if this has been implemented in Zope 2/Five)
But I'm trying to convince some of the Plone folks to work on that
during the PloneConf sprints. I'll touch this topic briefly as well, as
I'll try to get another shot at the "Customize" button for
That said, when you add a local utility in Zope 3, does it automatically
register itself by default?
It'd be quite annoying to have to:
1. add you thing that uses local utilities
2. oops, actually have to go create the local utility
3. great, now I have to register the damn local utility
4. finally, I can go back and tell my thing to use the new local utility
That's how it is. Of course, you could subscribe to IObjectAddedEvent
for those utilities and register them automatically when they're added.
Zope doesn't do this by default because it doesn't want to be in your
way. I sometimes have the several incarnations of the same local utility
in my site manager, and I don't want Zope to guess which one it should
Ideally there'd be some way to do steps 2-4 automatically, but at the
very least, having to manually do 3 seems superfluous, although I do
like the idea of being able to manually un-register a utility...
Right. Point is, you *can* automate. But Zope does no magic there. I
think that's a big lesson learned from Zope 2.
It functions as a container for indices.
Indeed, and how are these indices managed? For me, an Index is a local
(and potentially or maybe even definitely local to only that catalog)
utility for ICatalogIndex (or whatever it may be called). For me it'd be
nice to register the types of indexes using something like (and this is
all pseudo code):
...so you then have your list of addable index types.
Zope 3 does this via the standard "Add" menu. Go to the ZMI, add a
catalog and you'll see that inside the catlaog you'll get a different
"Add" menu. Voila.
Look at zc.catalog for lots more indices than Zope 3 comes with.
zc.catalog's configuration should give you more examples on how to plug
in new indices.
How _is_ this done in Zope 3?
I soooo wish I could RTFM you now, but my book ain't out yet. I already
gave you the gist: The catalog is the letterbox company for indices.
- the catlaog contains the physical index objects (IOW, indices are
added inside the catalog) and therefore provides access to them via
the standard dictionary API (getUtility(ICatalog).values() gives you
the indices of the current catalog).
- the catalog listens to object events and dispatches actions like
indexing and unindexing a document to its contained indices.
- the catalog has a minimal querying API, but you're usually better of
getting a hold of the indices directly, querying them and joining
their results the way you want it. hurry.query helps a lot there.
Of course, you don't *have* use the catalog if you don't like its
machinery. You could potentially place indices somewhere else and
register them indidivudlaly as local components. You will then have to
tell them yourself (via object event subscribers) when to index and
unindex objects. Note that the standard catlaog indexes have a
containment constraint in their interface that they can only be added to
catalogs. That's why they don't show up in the "Add" menu for regular
containers, only within catalogs.
Zope3-users mailing list