Scope. if you also did:-

<dtml-call "REQUEST.set('cid',cid)">

It would work too. The dtml-in variables are not available to sub-methods, this surprised me at first too, but, you get used to it :-)

If this is true, it's really counterintuitive and should be changed if at all possible. If it's specific to ZSQL methods or in otherwise confusing situations, then there's even more reason to change it... Anyone got any comments/suggestions? Chris

Chris Withers wrote:

...

<dtml-in case(cid=cid)>

of course, I actually mean <dtml-in "case(cid=cid)">

ZSQL Methods create their own namespace (I don't know why). You must explicitly pass them arguments. You can, of course, pass then entire namespace: <dtml-in "case(ns=_)"> ... </dtml-in> and in your SQL Method: <dtml-with ns> ... </dtml-with> This is, like all of my advice, completely untested and off the top of my head, but it should fly. -Michel

Chris Withers wrote:

...

ZSQL Methods create their own namespace (I don't know why). You must explicitly pass them arguments. You can, of course, pass then entire

IMHO, this isn't true.

Yes it is. I may not have stated it very clearly.

I have several ZSQL methods which have named parameters.

This is different.

It appears that they can get these parameters from REQUEST and possibly (I can't remember and haven't got time to check :( ) things like dtml-let and dtml-with without having to explicitly pass them which is why I was so surprised that dtml-in didn't work as expected.

When you call a method 'by name' (<dtml-var methodName>) then the DTML machinery will magically try and line up any arguments to that method with any names in the namespace. It will do this for any kind of method that accepts arguments, DTML Methods, SQL Method, ext methods, PythonMethods, and methods written in python of the object this() etc... _However_ if that method is a SQL Method then as soon as you enter the method any reference to <dtml-var name> in the SQL method will NOT find the name in the previous DTML namespace. If you want a name in the DTML namespace to match an argument, that's a different matter all together, and it will work, if you want to <dtml-var name> in a SQL Method and 'name' is in the namespace of a calling DTML method, then it won't work. -Michel

Um, more or less (apart from the quotes). The ZSQL Methods use namespace different from than normal DTML documents/methods (though I don't exactly know how). Therefore you have to call them explicitly with an argument.

Sometimes you do, sometimes you don't. I know that sometimes I can acquire ZSQL method parameters from the request. Sometimes I have to provide them explicitly. I haven't been able to figure out what the rules are, either. If anyone out there could explain this behavior I'm sure lots of us would be grateful. --jfarr

Jonothan Farr wrote:

...

Um, more or less (apart from the quotes). The ZSQL Methods use namespace different from than normal DTML documents/methods (though I don't exactly know how). Therefore you have to call them explicitly with an argument.

Sometimes you do, sometimes you don't. I know that sometimes I can acquire ZSQL method parameters from the request. Sometimes I have to provide them explicitly. I haven't been able to figure out what the rules are, either. If anyone out there could explain this behavior I'm sure lots of us would be grateful.

Hm, I _think_ I recall (but I can't test this right now) that the ZSQL method will only accept values that are given explicitly in its arguments and in that case it will also acquire them. That would make sense from a security point of view. Or perhaps it was a bit more complicated - I have to investigate this Rik