Script context discrepancies & Zope conceptual confusion
<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
Firstly, to address hosting, I'm currently using Hurrah (www.hurrah.com) who have been helpful, and who are noticeably cheaper than iMeme in any case... you might want to try them if you want external hosting at some point (they don't answer immediately, but the requests have been dealt with thoroughly). As to the operation of scripts and methods - it does get confusing - I can agree with you on that to some extent. However, when you've written some code in a document, and you wish to extract that into a separate script, then you can create a DTML method with much the same code - less changing required, so in certain circumstances it can reduce the amount of code changes written. Once you're used to this separation it starts to make more sense - DTML methods aren't designed to operate on themselves, so they work within the context of the referring document, which can make the code cleaner. It's an uphill struggle before it starts to become more natural (and in lots of occasions writing lots of debug code to figure out why you're getting the wrong list returned, etc), but it does start to make more sense after a while. I think the real problem is not that this feature exists - it makes the code cleaner in most circumstances - and some code transfer easier, as noted above - but that the feature is not particularly well documented, and it would be less problematic if the Help Docs, Zope Book, etc made the different contexts clearer. David 22/05/2002 13:32:53, "Corey Lubin" <lubin_c@bellsouth.net> wrote:
<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
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
"Into the abyss we stare, hoping that the abyss does not gaze so intently upon us"
participants (2)
-
Corey Lubin -
David Burton