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

[Jim Fulton]

Dave Parker wrote:
> 
> Jim Fulton wrote:
> 
> > Your analysis is flawed. Here's why.  The method gets called
> > recursively. The first time it is called, the namespace *is* passed
> > in, by Zope.  When it calls itself the second time, the namespace
> > isn't there, because the method doesn't pass it.  Lets work through this:
> 
> Blush - yup, you're right.  So ok I guess I just have an "issue" in my
> head then, which is...
> 
> > >  It strikes me that someone
> > > went to the effort to ensure that namespace gets passed down for me to
> > > *some* extent,
> >
> > That's right.  When a method is called by Zope or when you insert
> > it with the name attribute of the var tag:
> >
> >   <dtml-var name=methodA>  (aka <dtml-var methodA>)
> >
> > The namespace is passed in for you.
> 
> ...so why not take care of that for me *always*? You do it for me once,
> why not just keep on doing it? 

The difference is level and environment.  Expressions
are low-level. They provide low-level access and control.
With control comes resposnsibility.

> Put another way, what's the benefit to
> the user of parameterizing the namespace?

It is consistent with Python.  Since expressions are
defined to be Python, the semantics are expected to carry through.
In general, in Python, what you pass is what you get.  OTOH, 
there is some precedence in Python for having things passed for
you. In particular, the instance that a method is accessed through
is passed automagically.
 
> - It's not at all intuitive.
> 
> - In that I get namespace calling the function one way, but not another,
> it's inconsistent and therefore confusing

It's inconsistent because the languages are different.  For example, 
'-' is legal in HTML, and therefore DTML, names but not in 
Pthon names.
 
> - It adds a repetitiveness to the protocol that feels kludgy

Granted.

> - From an end-user perspective, I feel like I'm getting around a
> *problem* with Zope's logic

In this case, the problem was with your understanding of Zope's
logic.  This sort of thing will be an issue for most technologies.
OTOH, the fact that you didn't understand what was going on was,
at least partly, Zope's fault.

Although I think that the current situation is, on some level, 
justifiable, I'd also love to improve it.  While I understand
why it is necessary to pass "_.None, _", I'd love for it to 
be unnecessary.

After reading your rant, I've given some thought to this and
I think I might have an idea how to accomplish it. It does 
involve some, uh, hijinks under the hood, but I do think it is doable
and am in favor of it myself. I'll put a request into the collector
and will champion it with the Zope project management folks.
 
> So it's a "user friendliness" issue.  But I can guarantee you I'm not
> alone - we have a team of four doing heavy development in Zope and the
> *resounding* complaint is that Zope is rife with these apparent
> inconsistencies.
>
> I'm close to being done beating this issue, but while "apparent
> inconsistency" is in my head I'll thow out one I struggling with at this
> moment:
> 
> If I do:
> 
> <dtml-var "myMethod(value={'this':'that'})">
> 
> myMethod does not see "value" in the namespace 

Really? I can't reproduce this.

> whereas if I do:
> 
> <dtml-var "myMethod(value=['this','that'])">
> 
> myMethod sees value just fine.
> 
> So I can't pass in mapping objects??

Yes you can. Something else is going on. I just tried an 
example like yours and it worked fine for me.

I had method m1:

  <dtml-var value>

and called it from m2:

  <dtml-var standard_html_header>

  <dtml-var "m1(value={'this':'that'})">

  <dtml-var standard_html_footer>

and got:

  {'this': 'that'} 
  
along with other decorations from the standard 
header and footer.
 
Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.