[Zope-dev] Why is TemplateDict so opaque? -and- Have you seen this problem?

[Phillip J. Eby]

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.