At 06:45 AM 12/16/99 -0600, Dave Parker wrote:
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-->
Try this: <!--#var standard_html_header--> Depth: <dtml-var "methodA(_.None,_,counter=counter+1)"> <!--#var standard_html_footer-->
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
You will now see one of the two. Actually, DocumentTemplate will eventually raise a DTML call stack overflow exception, but you may think it's crashed because it might take a while to get the error. :)
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.
Horrible workarounds? Not really. Just make sure that if you're going to call any kind of DTML-ish thing with parameters, the first two positional parameters should be _.None and _ so that the current namespace is passed through. When you do a plain evaluation of such, the DTML machinery automatically passes them in, and you never see it happen. This is one of the really bad bits of DTML from a learning curve standpoint: it does magic behind the scenes for you that you really ought to be able to see so that you know how to do them when *you* need to do them.