[Grok-dev] Re: catalog indexes in Grok
Philipp von Weitershausen
philipp at weitershausen.de
Thu Apr 19 13:01:57 EDT 2007
Martijn Faassen wrote:
>>> Another directive you may choose to use is grok.name. This sets the
>>> name for the catalog. If you don't use it, an unnamed catalog is used.
>>> You can use grok.context and point to a class instead of to an
>>> interface. This works, but currently means indexes are created that
>>> index *everything* (like in Zope 2). Indexing not restricted to that
>>> class. This is because zope.app.catalog.attribute, to my knowledge,
>>> currently doesn't have that facility.
>> It shouldn't be too hard to customize that particular part of their
> Can you give me some clues as to what you have in mind? These are base
> classes, and I'd rather not create new indexes just for Grok. Or do you
> mean we should adjust zope.app.catalog.attribute directly and add a new
> feature to it? Or perhaps you have some clever idea in mind, which is
> what I'm hoping for.
Perhaps zc.catalog's extentcatalog could be used to do the appropriate
filtering. Not sure.
Anyway, here's a whacky idea to make this work. Let's say we have::
name = grok.Value()
description = grok.Text()
The index grokker would do this:
* create an interface with a predictable name (e.g.
current.module.IMammothIndexesAdapter) on the fly
* register the indexes to only pick up objects with this interface.
* register an adapter from the Mammoth class to IMammothIndexesAdapter
that proxies the indexed value. This could be done efficiently with
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev