<foreword optionalReading="true">Zope has seemed like an appealing option to me ever since I had first heard of it. As a C++ programmer, and an amateur user and lover of Python, the concepts behind Zope struck a chord with me.
From afar, I viewed it as an object-oriented web development environment with the perk that it integrated well with my new "pet language" (Python). The only thing was that it /wasn't/ an option, until now (my goals were too high for some of the free providers, and the commercial provider I came to, iMeme, decided to ignore me).</foreword>
With my new firewall-free connection, I installed Zope on my own system and got to work. I quickly came across some problems. Not the typical newbie-that-didn't-RTFM problems (well, ok, those came along too, but that was expected and they were easily dealt with), but conceptual problems, problems of understanding. In terms that strip the unimportant details from the situation, my wish was to have "/foo/bar/doc" include "/foo/doc" which would in turn include "/doc" (doc == some file implemented as a DTML document with an intended cumulative behavior). After figuring out how to access parent objects and accomplish what I wanted by duplicating the required DTML code into each "doc", I decided to encapsulate the work by placing it into a Python script living in the root folder. To my surprise, in addition to the obvious translation from DTML to python syntax, the switch from inline DTML to an python script changed the _behavior_ of the code. Where "this().aq_parent.aq_parent" once referred to the doc's grandparent ("/foo" in the case of "/foo/bar/doc"), the supposedly analogous "context.aq_parent.aq_parent" referred to the doc's great-grandparent ("/" in the case of "/foo/bar/doc"). As was inferred by the mentioned results, simple tests using absolute_url indicated that "context" infact referred to the doc's containing folder rather than the document itself, the object being viewed -- the object upon which the script should have been acting upon. I must have misunderstood the context variable, I thought as I reread that it "." Well, the document /is/ the object being acted upon when being viewed, not the folder it happens to be sitting in, I argued to a more experienced Zoper @ opn/#zope, hoping to clear up my understanding of the way Zope works. Judging solely from the behavior of Python scripts as they seem to work now, I was just about ready to change my view of Zope and assume that the only item analogous to "objects" of OOP-speak were Folders and that Documents should just be considered views of the object, rather than objects of their own. That is, until we eventually realized we agreed with each other, and in response to my question as to whether other procedure-like objects (DTML Methods,...) act the same way, he admitted that DTML Methods would behave in the way I expected my Python script to. The remaining questions were clear... - What behavior is intended by the Zope designers/developer? - If Python scripts called from within DTML Document's /are/ supposed to have their context bound to the document's parent, rather than itself, what is the reasoning behind the discrepancy? To me the following only seems logical: A call to a script "/script" from within the source of "/foo/bar/doc" should match the calling behavior of a visit to "/foo/bar/doc/script". coreyLubin ...who ended up making this mailing into much more of a story than the developer-targeted question that it is