[EMAIL PROTECTED] wrote: > >self.catalog_object(obj,'/'+join(self.getPhysicalPath(),'/')+'/'+obj.thread_path()+'/'+`id`) This is very bad for many reasons :( > When I went to look at the catalog entries after adding a new site within > a folder called myfolder, I noticed the new entries showed up as: > > /newsquish/<id> > > When I clicked on the link, I received an error saying it can't find the > object. I don't think a leading '/' should be supplied to > catalog_object(). You are quite correct, but the problem in this case was more serious. getPhysicalPath(), AFAIK, is a recursive method that goes up the acquisition tree. Unfortunately, in __init__, where the sample articles are created, self isn't acquisition wrapped and so you: a) don't get your leading '/' for free b) don't get path info for further up the tree from the SquishSite (hence the manage_catalogView page is broken) This was the major thing to be fixed with some judicious use of a 'parent' argument to the __init__ method and a bit of wrapped=self.__of__(parent) magic. > I tried to update the catalog, which promptly removed > all the postings from the catalog. That I never experienced... > When I re-cataloged the postings, the > entries were now showing up as: > > //myfolder/newsquish//<id> My second mistake :( thread_path returns the thread path with a '/' prepended, so mine was redundant. d'oh! So there ya go, all fixed now though (allegedly) and checked into CVS. Lance, thanks for all the testing, it's very much appreciated :-) cheers, Chris _______________________________________________ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
