Stephen Simmons wrote:
> Ideally the publishability of an object would be an internal property of
> that object, not something that is set externally via rules in SiteAccess.
> It's been a little while since I last looked at SiteAccess, but wouldn't
> using SiteAccess force you to store publishable objects in one part of the
> database hierarchy and non-publishables in another? If you wanted
> publishables and non-publishables all mixed up in the same folders,
> SiteAccess's rules might get a bit complicated.
Yes, this is not a neat solution, unless you have already designed your
site to use siteaccess in this way.
> Another approach could be to:
> - create a folder that does a RESPONSE.setStatus(404) as the URL traversal
> machinery passes it. This sets up the default condition of 'NotFound' error
> for the URL
> - at the end of the URL, if the final object is publishable or the final
> item is a publishable method called on a publishable object, do a
> RESPONSE.setStatus(200) to say 'OK'.
Even if you don't reset the status to 200 and it remains as 404, the
page will still get sent to the browser. You don't want to mess with the
traversal machinery on this, as you want traversal to continue to work
as it does now.
I think your intent is to block direct requests from a web-browser for
particular objects. The easiest way of doing this is to check
REQUEST.steps[-1] to see if it equals the current object's id.
If you want this to be fairly transparent, perhaps based on a particular
permission or property, then I think you'll need to patch part of Zope,
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -