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, hikinks, but should be doable. I'll submit this as a feature request to the collector and champion it with the product management folks here.
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.