The more I learn about Zope, the more I like. Mostly.
I’ve always had a keen interest in software composition, and so was particulary impressed with Zope’s notion of “acquisition”, which is just composition by aggregation. What’s really novel here is not that, which has been done before, many times, but the binding of the URI hierarchy to containment relationships. Kudos for that.
One of the very few criticisms I have about Zope though is the use of “URL Traversal”, to locate scripts named in a URI. I added some comments to that page (itself, a nifty feature!), as you can see there;
I was thoroughly impressed with most of what I’d seen in Zope, but not so much with this feature. Perhaps it’s convenient, but it’s also quite dangerous in general I think. The examples of “feed” and “wash” are are called “unsafe” methods in Web architecture terms (http://www.w3.org/TR/webarch/); that is, they change the state of the object. Therefore they, shouldn’t be invoked with GET, as Googlebot might come along and accidentally feed your hippos. If you want to change the hippo directly to the fed state, use PUT with a document which represents the state of that fed hippo. If you just want to give him food (that he may or may not choose to eat), use POST with a description of the food.
I also wonder if the same misunderstanding about GET vs. POST was responsible for some problems I noticed with object publishing. For example, both GET and POST end up invoking the “index_html” method (eek, a horrid name) of an object (basically the equivalent of doGet() for you servlet fans). It’s odd that the object model define ambiguous dispatch behaviour for GET/POST, yet define proper dispatch behaviour for PUT, HEAD, and the WebDAV extensions. Perhaps a legacy mistake that’s too costly to fix? Dunno. But the more I read the publishing section, the more it seems that Zope has a bit of split personality in supporting both the Web and RPC models.
Hopefully that doesn’t get in the way of what I want to do with it.
no comment until now