All this I absorbed osmotically, from other examples of Zope usage, without really having much of a clue about the mechanics of acquisition, or its algebra as explained in Jim Fulton's now-famous lecture at IPC8, and also in another write-up by Dieter Maurer.
Until recently, despite my ignorance of these matters, I never ran into the kinds of conflicts that can occur when you mix the containment flavor of acquisition with the context flavor. But last week, while adding a new feature to my magazine-production application, I finally dipped my toe into the waters of the deep magic.
Here's the background. When the magazine is published to the Web, I base each article's URL on a short label. Sometimes, an article has to go to print with a "forward reference" to a future article whose URL is not yet assigned. So, I decorated the <dtml-tree> with a new per-article-folder link used to pre-assign that label in these cases. The link invokes code that sets a url_label property on the article's Folder. I also added to the <dmtl-tree> logic some code to display the value of that property.
To test my ability to display the property, I used a DTML Document, called test, containing just this expression:
<dtml-var url_label>
But, no matter from which context I called test, the result was always 'xxx.' Here's why. At some point, I had set that property on the root Folder, Production, and given it the value 'xxx.' Subsequently, my per-article-Folder code was (as it should) adding other url_label properties. The resulting structure was:
Production <- url_label = xxx
addFile
test
2001-08
2001-08
article_1 <- url_label = abc
Why would the URL 2001-08/article_1/test print the value 'xxx?' Because test acquires the property in two ways: by containment, and by context. And, because -- as Jim Fulton's acquisition algebra paper explains -- the former takes precedence over the latter.
The fix, in this case, was simply to delete the unneeded url_label on the Production Folder. But suppose it had to exist, for some other reason? How could you choose context over containment? As it turns out, my stand-alone DTML Document test was a red herring. Within the <dtml-tree> that's the engine of this application, the contextual property is the one that's found first and used.
When you write a Python Script -- the newer, more integrated, but less powerful and dangerous version of an External Method -- the choice becomes explicit. Such a script receives two namespaces, appropriately called context and container. A Python Script called testPyScript, which contains the following code:
if (which=='context'):
return context.url_label
else:
return container.url_label
produces these results:
2001-08/article_1/
testPyScript?which=context -> abc
2001-08/article_1/
testPyScript?which=container -> xxx
Whew! This is indeed a bit of a "brain-tweak." Quite honestly, I still feel like a novice when it comes to understanding this stuff. But as a novice, I'm nevertheless able to do some really useful things with Zope. Powerful magic like acquisition is one reason why. Brilliant integration of that magic into a Web application server is the other.
Final note
I asked Amos Latteier and Michel Pelletier, authors of The Zope Book (available online and, soon, in print),
to review this column for accuracy. Michel offers this useful
clarification:
The "wrapping" that acquisition does is actually a cleaner, simpler model that just happens to end up turning into a complex pile of algebra if you care. Most of the time, it works just like people think it does.
One easy way to think about it is, you can acquire things from objects if you are in their context. You're in their context if they are an element in your URL path.
Byte Newsgroups:
Join Jon and the others in various, ongoing discussions in the newsgroups. |
Jon Udell (http://udell.roninhouse.com/) was Byte Magazine's executive editor for new media, the architect of the original Byte.com, and author of Byte's Web Project column. He is the author of Practical Internet Groupware, from O'Reilly and Associates. Jon now works as an independent Web/Internet consultant.
