[Zope-dev] feedback wanted on ZCatalog changes...

[Anthony Baxter]

>>> Michel Pelletier wrote
> > and
> > fixing the "can't index attributes acquired from higher than 
> > the enclosing
> > folder" from ZopeFindAndApply.
> I've not been bitten by this one, so I'm not sure I understand.

Ok. I have a bunch of folders with help files in them - something
like

featureA/help/helpfolder1/fileA
featureA/help/helpfolder2/fileB1
featureA/help/helpfolder2/helpfolder2a/fileB2
featureA/help/helpfolder3/fileC
featureA/help/helpfolder4/fileD
featureB/help/helpfolder5/fileE
featureB/help/helpfolder6/fileF
featureB/help/helpfolder7/fileG  
(only with many more helpfolders and files)

and I want to full text index them, and also index them by a 
bunch of attributes. One of these attributes is 'featureName', 
which is a property of the featureFolder (eg featureA). The
current code breaks the acquisition at the enclosing folder, 
so that it can see whether the folder has an objectItems() method.
It then looks up objects in this no-acquisition folder, and indexes
them. This means that when indexing, you can't index on an attribute
from higher up the acquisition chain that the enclosing folder
object.

For my application (which is in production use[*1], btw - and has been
getting all sorts of nice feedback) I could either:

fix this
or
make sure to copy the 'featureName' attribute to all folderish
objects created inside a featureFolder (and to their children, &c.) 
This would bite in a major major way - if I changed a featureName, 
I'd have to change it in all subfolders.

> When indexing with find, you want objects to try and acquire attributes
> and index the value of that acquried attribute if it can do so?

Sure - if you're asking for an attribute that can be acquired.

> Hmm.. I think context could come up and bite us here, The request to
> index the object may have a different acquistion context then the
> request that runs the query, thus 'find' may index values for objects
> that other people may not be able to see in their context, or even have
> permission to see.  

That could be a documentation issue - "make sure to run the findandapply
in a context that is appropriate". I still think that's better than the
current behaviour, where you can index acquired attributes, but only if
they're acquired from the immediate aq_parent.

> By not acquiring, you limit the functionality, but
> avoid having to run catalog queries through the security machinery; god
> help us all if that ever happens.  Maybe that doesn't make sense, what
> do you think?  Can you reproduce a security violation with your patch?

Nope. Not in my application. In _theory_ I can see that you could 
have a security problem if you weren't aware that the indexing
occurs in the context running the findandapply request - but then,
it does already (see above). Heck, you could even make it a toggle
option in the page 'index acquired objects'. 

The other (currently unreleased) use for this is in my workflow
code. I have something like (but not really) an SQL method with
a direct traversal class, which then gets called with dtml methods
acquired from the parent - so

wffolder/meth1
wffolder/meth2
wffolder/meth3
wffolder/sqlInstanceLookup

and I need to be able to catalog
wffolder/sqlInstanceLookup/0001/meth1
wffolder/sqlInstanceLookup/0001/meth2
wffolder/sqlInstanceLookup/0001/meth3
wffolder/sqlInstanceLookup/0001/meth4

Without the ability to index acquired attributes, this becomes
hellishly difficult.

Anthony

[*1] go to www.ekit.com, sign up for an account (about 3 clicks) then
click on 'help'. The tree on the left is populated from ZCatalog searches,
which amongst other thing only show help for the stuff your account is
able to do, the search box is a textindex of the files (which, again,
only searches the help for stuff your account can do), and the lookup of a
help document (like, when you click on a help link) will hit the ZCatalog
to look up the file's path. The help files themselves are maintained by
a non-techie in dreamweaver, and uploaded into zope.  ZCatalogs rock :)