Re: [Zope3-Users] Re: looking for something like getUtilitiesFor...
Philipp von Weitershausen wrote: Utilities are never created when they're looked up. They're created when registered. Singletons (instances) are registered with the utility registry, never factories. Ah, yes, of course, I think I'm looking for local utilities... and all I'm then doing with the list is generating a drop-down for people to select from... getUtilitiesFor is all we have. If you want that drop-down, consider using UtilityVocabulary from zope.app.component.vocabulary, e.g.: class FooUtilityNames(UtilityVocabulary): interface = IFoo nameOnly = True classProvides(IVocabularyFactory) Register that as a utility: utility component=...FooUtilityNames name=Foo Utilities/ Then you can refer to it from a schema definition (Choice field). 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?) Also, more theoretically, would you see indexes for a catalog as being local utilities. If not, what would you see them as being? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: looking for something like getUtilitiesFor...
Philipp von Weitershausen wrote: Chris Withers wrote: Philipp von Weitershausen wrote: Utilities are never created when they're looked up. They're created when registered. Singletons (instances) are registered with the utility registry, never factories. Ah, yes, of course, I think I'm looking for local utilities... But even global utilities are *first* instantiated from their factory, then registered as singleton instances. Yes, that's true, but unrelated... In fact, in this case, the utilities that are global are just python functions marked with directlyProvides ;-) 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) 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 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... Also, more theoretically, would you see indexes for a catalog as being local utilities. If not, what would you see them as being? The catalog is the local utility. That's also true, but also not really what I was getting at ;-) 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. How _is_ this done in Zope 3? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: looking for something like getUtilitiesFor...
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 s 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 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
