Squishdot and ZCatalog, Zope 2.2
odysseus@acedsl.com wrote:
I checked out the latest CVS source, and noticed you called self.catalog_object() like this:
self.catalog_object(obj,'/'+join(self.getPhysicalPath(),'/')+'/'+obj.thread_path()+'/'+`id`)
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(). I tried to update the catalog, which promptly removed all the postings from the catalog. When I re-cataloged the postings, the entries were now showing up as:
//myfolder/newsquish//<id>
Sounds like Zope 2.1.6 to me.... If you try it on Zope 2.2.0 it works fine, for me anyway :S
Also, the setItem() method in the Squishsite class (different from the setItem() method in the Posting class) is the only place where using the absolute_url() method doesn't work.
It's cos the 2.2.0 implementation of absolute_url requiers a REQUEST, which it doesn't get in setItem(). This is fixed in 2.2.1 apparently...
I've noticed in all the other methods it's called from, it returns the proper result. The same actually goes for the getPhysicalPath() method, all the double slashes aside. Notice in the above examples, when the postings were initially loaded, getPhysicalPath() returns only newsquish, whereas everywhere else, it returns /myfolder/newsquish .
haven't noticed this at all... what version of Zope are you using?
Let me know if you need any help,
Oh, I need help alright, for trying to move Squishdot to Zope 2.2 in the first place :( My current fun is with <dtml-in attachment> which works fine in the edit form on the management interface but throws a KeyError on 'file_name' when I try and use it in the posting_html DTML method... Any ideas/solutions greatly recieved :S cheers, Chris
On Mon, 21 Aug 2000, Chris Withers wrote:
odysseus@acedsl.com wrote:
I checked out the latest CVS source, and noticed you called self.catalog_object() like this:
self.catalog_object(obj,'/'+join(self.getPhysicalPath(),'/')+'/'+obj.thread_path()+'/'+`id`)
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(). I tried to update the catalog, which promptly removed all the postings from the catalog. When I re-cataloged the postings, the entries were now showing up as:
//myfolder/newsquish//<id>
Sounds like Zope 2.1.6 to me....
If you try it on Zope 2.2.0 it works fine, for me anyway :S
I'm running 2.2.0 (I swear!), with the latest Hotfix. I create a Squishdot Site named groucho at the root. When I go to the Options tab and hit re-catalog button, then go to the Cataloged Objects tab (which I had to uncomment in the source to access), the catalog entries are listed as: //groucho//966886273 //groucho// ...and so on. I also create another squishdot site under the folder /myfolder , called harpo . When I go to the Cataloged Objects tab, the articles are listed as: /harpo/966886570 /harpo/ ...and so on. This isn't right. So I go to the Options tab, hit the re-catalog button, then go back to the Cataloged Objects tab, and they're now listed as: //newfolder/harpo//966886570 //newfolder/harpo// ...whatever. This hasn't happened to you? Is there anyone out there who can test this out as well, with the Squishdot from CVS?
Also, the setItem() method in the Squishsite class (different from the setItem() method in the Posting class) is the only place where using the absolute_url() method doesn't work.
It's cos the 2.2.0 implementation of absolute_url requiers a REQUEST, which it doesn't get in setItem(). This is fixed in 2.2.1 apparently...
Had I known that REQUEST requirement was a bug, I would've reported it earlier. Which is the preferred method then, absolute_url() or getPhysicalPath() ?
I've noticed in all the other methods it's called from, it returns the proper result. The same actually goes for the getPhysicalPath() method, all the double slashes aside. Notice in the above examples, when the postings were initially loaded, getPhysicalPath() returns only newsquish, whereas everywhere else, it returns /myfolder/newsquish .
haven't noticed this at all... what version of Zope are you using?
Zope 2.2.0, I swear!! -Lance
odysseus@acedsl.com wrote:
I'm running 2.2.0 (I swear!), with the latest Hotfix.
This is the only possible difference I can see :S Can you try The Squishdot CVS on a plain, boring, stock Zope 2.2.0 install? (no other patching, no hotfixes, hopefully not even any other products installed...) cheers, Chris
Had I known that REQUEST requirement was a bug, I would've reported it earlier. Which is the preferred method then, absolute_url() or getPhysicalPath() ?
getPhysicalPath should be used for cataloging, AFAIK, since it's not affected by virtual hosting... cheers, Chris
Oh, I need help alright, for trying to move Squishdot to Zope 2.2 in the first place :( My current fun is with <dtml-in attachment> which works fine in the edit form on the management interface but throws a KeyError on 'file_name' when I try and use it in the posting_html DTML method...
Any ideas/solutions greatly recieved :S
Did you figure this one out yet? I started taking a look at it now, and I think it's a security issue. If I put Squishfile.py into cheat mode (__allow_access_to....) It works fine. -- --Lance
participants (3)
-
Chris Withers -
Lance -
odysseus＠acedsl.com