Chris Withers wrote:
Okay, tracked down what's happening, can't understand why :-(
Now I can... convoluted but with a simple answer ;-)
As to why the object is on the top of the namespace, I dunno whether it's dtml-in or ZCatalog that's responsible...
The reason for this, was because the object was being acquired. The naming similarity was pure chance. I had an index called TestCase in the catalog, the same name as the DTML method for the form. I _didn't_ have a column called TestCase in the ZCatalog MetaData, so when the result-displaying DTML method tried to dtml-var it, it was acquired, and hence the method was plopped on top of the namespace. The actual problem is that ZCatalog was using the indexes instead of the metadata when telling Z Search was results form to build. The following patch solves that, I'm sure I put it in the collector when I moved Squishdot to use ZCatalog too :-S cheers, Chris --- zcatalog.py.old2 Sun Jan 28 20:56:06 2001 +++ zcatalog.py Sun Jan 28 21:00:09 2001 @@ -486,7 +486,7 @@ def _searchable_result_columns(self): r = [] - for name in self._catalog.indexes.keys(): + for name in self._catalog.schema.keys(): i = {} i['name'] = name i['type'] = 's' PS: I won't bother with the collector on this one, since both relevent people are already being CC'ed ;-)