[Grok-dev] Re: catalog indexes in Grok

[Philipp von Weitershausen]

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

   class Mammoth(grok.Model):
       pass

   class MammothIndexes(grok.Indexes):
       grok.context(Mammoth)

       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
   zope.proxy.decorator.Decorator.



-- 
http://worldcookery.com -- Professional Zope documentation and training