From: Chris Withers <chrisw@nipltd.com>
It looks like REQUEST.steps is the replacement for PARENTS? Is that so?
Actually, REQUEST.steps has always been there -- it's the list of *ids* that were traversed. This may or may not correspond to the ids of the PARENTS, depending on whether an object with a __bobo_traverse__ inserted extra objects or replaced itself in PARENTS. Then there is REQUEST._steps, which is new, and which is (as the _ implies) for internal use only. It's a pre-url-quoted list of steps, affected by virtual hosting, which is used to construct URLn and BASEn. Right now, I've working in a CVS branch on new REQUEST variables called URLPATHn and BASEPATHn, which are analagous to URLn and BASEn but only contain the path portion of the URL. Then all SCRIPT_NAME uses should be replaced with BASEPATH1, etc.
Small grumble: REQUEST['TraversalRequestNameStack'] is a bit of a long-winded name :P
Agreed. Jim pretty much mandated a name that (1) lives in 'other', rather than being an attribute, and therefore (2) is very, very unlikely to clash with other people's REQUEST variable names.
So now you have to restart Zope to undo a screwup? I guess __no_before_traverse__, or whatever it was, was a security whole, or something?
No, it's just not specific enough. Now that the before-traversal hook is part of Zope, other services may want to use it, and so it shouldn't have a global on/off switch. As of SiteAccess 2.0b3, you can insert "_SUPPRESS_SITEROOT" and/or "_SUPPRESS_ACCESSRULE" into your URL in order to turn off a single SiteAccess object (the one which would have triggered at that point in the URL).
Hmm, the example for Multiple Sites isn't very robust :-( http://www.zope.org/Members/4am/SiteAccess2/vhosting
I didn't spend a whole lot of time fortifying it. It's just meant to be an example, after all. I wasn't expecting so many people to paste it into their applications without understanding what it does. :-) Cheers, Evan @ digicool & 4-am