Hi, This is weird, I've got a solution but I don't know why I need to use it... I have a DTML Document that uses two ZSQL Methods, something like: <dtml-in item> ...the item ZSQL method returns cid... <dtml-var cid> <dtml-in case> ...the case ZSQL method takes cid as a required parameter </dtml-in> </dtml-in> Now, using this returns an error: Bad Request: [cid] which I've grown accustomed to seeing when a requried parameter is missing. However, if I dtml-comment out the second dtml-in, it works fine and the correct cid is displayed by the dtml-var. The only way I can get it to work is to make the second dtml-in look like: <dtml-in case(cid=cid)> I really don't understand why I need to do this and why the 'case' ZSQL method doesn't just pick up cid from the current namespace... Any ideas? Chris
+----[ Chris Withers ]--------------------------------------------- | > <dtml-in case(cid=cid)> | | of course, I actually mean <dtml-in "case(cid=cid)"> 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 :-) -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|
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:
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.
This is not true. Method A: <dtml-with "_(bob='uncle')"> <dtml-var B> </dtml-with> Method B: <dtml-var bob> _will_ print 'uncle'.
If it's specific to ZSQL methods or in otherwise confusing situations, then there's even more reason to change it...
It is specific to ZSQL Methods, they create their own fresh namespace. There may be a good reason, I can't think of one. -Michel
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
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. I have several ZSQL methods which have named parameters. 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. Can anyone who knows say why this is the case and exactly what the critera are for something being 'visible' to a ZSQL method's parameter list? HSCH, Chris
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
Chris Withers wrote:
Hi,
This is weird, I've got a solution but I don't know why I need to use it...
I have a DTML Document that uses two ZSQL Methods, something like: <dtml-in item> ...the item ZSQL method returns cid... <dtml-var cid> <dtml-in case> ...the case ZSQL method takes cid as a required parameter </dtml-in> </dtml-in>
Now, using this returns an error: Bad Request: [cid] which I've grown accustomed to seeing when a requried parameter is missing. However, if I dtml-comment out the second dtml-in, it works fine and the correct cid is displayed by the dtml-var.
The only way I can get it to work is to make the second dtml-in look like: <dtml-in case(cid=cid)>
I really don't understand why I need to do this and why the 'case' ZSQL method doesn't just pick up cid from the current namespace...
Any ideas?
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. Rik
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
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.
I think this is my point exactly ;-) It all seems really inconsistent and I was wondering if anyone could say exactly what the 'rules' were and why? cheers, Chris
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
participants (5)
-
Andrew Kenneth Milton -
Chris Withers -
Jonothan Farr -
Michel Pelletier -
Rik Hoekstra