[Zope-CMF] Re: proposal for cmf:indexable directive

[pete]

Hi,

I've a question: why declare the specific attributes for 
indexing/metadata at all?  I couldn't see what binds the cmf:indexable 
declaration to a particular adapter in the example, so I was wondering 
if we could do without.  Suppose we had an adapter like:

<adapter
  name="NavigationProperties"
  for="IContent"
  provides="ICatalogVariables"
  factory="addNavigationProperties"
  />

where ICatalogVariables defines a single method that returns a dict of 
properties and values to index.  (FWIW I put an implementation of this 
interface in the tracker a while ago (#378) plus some code to expose 
plone's indexing registry as this interface.)  It could even define a 
second method that indicated the available properties.

The catalog could work out everything that provides the 
ICatalogVariables interface, and calculate the properties to index. It 
will already index/record them as metadata if they have been added as 
metadata/indexes in the catalog, so not sure what all this declaration 
really buys us.

It does get us some cool stuff if we want to automatically set up 
indexes using the configuration or check that indexes/metadata exist in 
the catalog.  But wouldn't the index configuration be part of a CMFSetup 
profile?  In which case it would start living in two places, which could 
get confusing.  Also, wouldn't having something that sets indexes up 
automatically cause a conflict when you need to add a new type of index 
to optimise out a hotspot?

Having seen data go into the catalog, out the other side and into the 
bin when I've forgotten the index, some way of checking thar 
indexes/metadata exist would be useful.  But perhaps it's preferable to 
log this to the event log or something, rather than add new directives? 
  I'm not clear about what the pros and cons are of new directives vs. 
using code, perhaps someone with more experience has some ideas?

Anyway, just some thoughts.  It would be good to really get the catalog 
to be a 'service' with hooks that things can register with in a simple 
way, rather than having to do quite so much to wire them in.

Cheers,

pete


whit wrote:
> here is a sketch of how a working "indexable" configuration would look. 
>  Names subject to improvement.
> 
> ------------
> 
> <configure xmlns="http://namespaces.zope.org/cmf"
>            xmlns="http://namespaces.zope.org/zope">
> 
>  <adapter
>   name="SearchableText"
>   for="IContent"
>   provides="IIndexable"
>   factory="SearchableTextExtractor"
>   />
> 
>  <adapter
>   name="folder_order"
>   for="IContent"
>   provides="ICatalogMetadata"
>   factory="folderOrderCalculator"
>  />
> 
>  <cmf:indexable
>   for="IContent"
>   attributes='SearchableText
>               path
>               folder_order'
>   metadata='folder_order' />
> 
>  <!-- or this for interface lovers --/>
> 
>  <cmf:indexable
>   for="IContent"
>   attributes='IContentIndexableAttrs'
>   metadata='IContentMetadataAttrs' />
> 
> </configure>
> 
> -------------
> 
> Our primary goal was is to be able to catalog non-direct
> attributes as both indexes and metadata.  This straight forward to 
> accomplish.
> 
> Eventually, I think it makes sense, as content gets happily dumber, that 
> all indexing should work this way.
> 
> For backward compatibility, a default adapter could return direct attrs 
> from an object for indexing.
> 
>  <adapter
>   provides="IDefaultIndexable, IDefaultMetadata"
>   for="*"
>   factory="directAttrAccess"
>  />
> 
>  <cmf:indexable
>   for="*"
>   attributes='*'
>   metadata='*' />
> 
> Ultimately, if you didn't need back compatibility, you could override 
> like this:
> 
>  <cmf:indexable
>   for="*"
>   attributes='None'
>   metadata='None' />
> 
> then developers could determine class by class and interface by 
> interface (and perhaps even by event) what was called when an object is 
> indexed, thus lowering the overhead of cataloging.
> 
> Some other niceties come to mind when thinking about this that may not 
> be inially easily attainable; the main two are installation of indexes 
> via configuration and the validation of index existence by the 
> cmf:indexable handler.
> 
> I look forward to y'alls comments.
> 
> -w
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF at lists.zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
> 
> See http://collector.zope.org/CMF for bug reports and feature requests
>