Evan,
[Essentially: Why doesn't acquisition scan the whole database?]
Did you realize that this is what your questions boil down to? <wink> Do you really want to wake up every object in the ODB if you make a typo in a property name? Be sure to specify what order objects are searched; this is important!
Yeah, this is basically what I was saying. Sounds pretty simple-minded when you put it that way. Another one of those "seemed like a good idea at the time" sort of things.
Seriously, one of the most powerful aspects of acquisition is the way it lets you control the search context and ordering. You decide which objects should be included and which are irrelevant, and what overrides what.
It's not clear whether you understand the distinction between the containment hierarchy and the acquisition context. The normal structure
I think you've hit the nail on the head. I didn't understand that there was any difference between the two. I thought the acquisition context was rigidly defined by the hierarchy.
of the ZODB, with nested folders containing methods and objects, is a familiar organizational convenience. Object IDs are unique *within their container*, but not
Right, and I understand "their container" to mean the default acquisition context provided by the hierarchy, not just an object's folder.
globally. The hierarchy also provides a *default* acquisition context for each object, since the bare minimum context for an object is the straight line defined by its absolute URL -- the list of containing objects.
Acquisition context can be much more convoluted than simple containment, however. At *each step* in the resolution of a URL, an object can be acquired from *any previous object* in the URL. This means that given "A/B/C/D", "A" must be in the root, "B" must be in "A" *or the root*, "C" must be in "A", "B", or the root, etc. Essentially, a URL builds an "environment" (I prefer 'context') step-by-step. You can leap around in the current environment with each new step, and then the target object or method is rendered in this environment.
The canonical example of this is the standard_html_* objects. The root always contains default values for these, which can be overridden by including a folder in your URL which contains objects of the same name. You can thus refine your requirements by inserting objects into the URL. One could, for instance, have a URL like "/styles/fancy/framed/extras/js/flash/docs/MyDoc" which accesses the same object as "/docs/MyDoc", but tells it to render using fancy, framed HTML with JScript and Flash animations.
Wow. This is a fairly mind-blowing concept. You're saying I can pick and choose the stops I make on my way to an object and thereby create a unique collection of contexts (with their associated methods) that can be used to render the final object in the URL? So if I wanted the same information, say Info1, to be formatted for three different audiences, Aud1, Aud2, and Aud3, then I could (after writing the necessarily individualized methods for each audience) have three links like this: Root/Aud1/Info1, Root/Aud2/Info1, Root/Aud3/Info1, even though the containment hierarchy didn't actually reflect any of these URLs in its structure? I'm going to have to think about this some more. It seems almost like a kind of on-the-fly method inheritance. Zope gets deeper every time I look at it.
I think Zope is a marvelous programming environment, and I think it represents a much bigger shift in the web development paradigm than it seems at first glance. Regardless of my complaints about acquisition, I'll be sticking with it.
True enough, and good for you!
By the way, did you have any suggestions on my problem with getting a "multi-context" path (e.g., Root/Aud1/Info1 or Root.Aud1.Info1) out of a lines property and rendered using the looping construct you showed me earlier? I know it's something simple, but I can't find a helpful reference to it anywhere. Thanks again for your time and patience. Chris