[Zope] Script context discrepancies & Zope conceptual confusion

[Corey Lubin]

<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