[Zope-dev] Why is TemplateDict so opaque? -and- Have you seen this problem?
Dave Parker
dparker@globalcrossing.com
Thu, 16 Dec 1999 06:45:27 -0600
[sorry folks, I'm tired, so this is halfway to a rant :-( ]
I'm trying to do a work-around for the "namespace goes away after two
levels of dtml method calls" problem with an XXXPythonMethod, and have
now hit another wall as regards accessing the namespace enclosing the
XXXPythonMethod.
So I'm sitting here trying to figure out where this variable of mine is
hidden, and I'm thinking I should be able to get there via the _
instance of TemplateDict. Well....
I'm not happy that I now know what TemplateDict is - I really wish I
hadn't had to go there, but now that I'm there I have a much better
understanding of why it is impossible to get information out of it; it
has "do you have this key" and "get the value of this key" and
absolutely nothing else.
Is there a reason for this? I can think of *countless* times when the
ability to just have a *glimpse* of my namespace would have saved
hours. Is there a possibility that you could make the thing look more
like a mapping object, with keys() and values() and items() and such?
It'd sure save a ton of time. Some kind of tag to pretty-print the
namespace would be great too.
...
But then, actually, not having to deal with the namespace going away
problem would have saved even more time. I'll describe it briefly to see
if it rings any bells:
Imagine a dtml method called methodA that looks like this:
<!--#var standard_html_header-->
Depth: <dtml-var "methodA(counter=counter+1)">
<!--#var standard_html_footer-->
and you call it from a browser as methodA?counter:int=0
You'd expect one of these:
a) zope locks up/crashes because of the recursion
b) methodA bails out because someone detects recursion or exceeds a
stack limit of some sort
What you *get*, however, is the very suprising:
Error type: KeyError
Error value: standard_html_header
And if you rip out the reference to standard_html_..., you'll get the
equally baffling:
Error type: NameError
Error value: methodA
In practice, you'll find that this disappearing act occurs at about the
third level of expression evaluation.
Ring any bells? It requires *horrible* workarounds when you run into
it.
Ok, thanks for putting up with this.
Dave Parker
Sr. Software Engineer
GlobalCrossing