[Zope3-Users] Re: looking for something like getUtilitiesFor...

[Philipp von Weitershausen]

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?

Yes, exactly.

> (now I'm dying to know if this has been implemented in Zope 2/Five)

No :(

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 
template-based views.

> That said, when you add a local utility in Zope 3, does it automatically 
> register itself by default?

No.

> 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 
take now.

> 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):
> 
> <utility provides="catalog.interfaces.Index"
>          factory="catalog.fieldindex.FieldIndex"
>          name="Field Index"/>
> 
> <utility provides="catalog.interfaces.Index"
>          factory="catalog.textindex.TextIndex"
>          name="Text Index"/>
> 
> ...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. 
That means:

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

Philipp