At 04:00 PM 8/16/99 -0700, Bradford Hull wrote:
Try this... let's say your INSERT or UPDATE method is called 'do_update'... Your DTML would look like:
<!--#call "do_update(param1=var1,param2=var2)"-->
That's basically it. Use a #call tag and put double quotes around a function call to the ZSQL method, passing in as keyword parameters all the variables that it needs to do the update or insert.
This is probably the information I need right now, except that there's severe ambiguity in it if I don't already know how to refer to the args. That is to say, at the point in the routine where I have to do this (which you didn't tell me I need to write, by the way, and neither did the docs, but Martijn Faassen did) where I put this call, there are only 2 ways I can think of to try to get the value for my parameter: <dtml-call "add_resp(email=email)"> or <dtml-call "add_resp(email=<dtml-var email>)">
The first fails when I run it, which seems reasonable as silly as it looks, and the other gets a compile-time error when I try to store the edited script. No other expression in 50-75 tries has actually stored a value in my database yet, though many have run without throwing an exception or error.
What error does it fail with? I must have missed your original question on this. Could you repost the methods in question? By the way, your first example is the 'correct' one (i.e., the one that 'should' work). You cannot nest DTML tags within themselves. Two more questions: does add_resp work if you use its 'Test' tab? Is 'email' the only variable referenced in the SQL, or are there others?
See how easy it is to be ambiguous, when you know the turf and your reader does not? Thanks for the tips, and if you can clarify the point above I'll thank you again, because now I'm so close I can smell database update...
It does work, believe me. Up until about this time last year, I had a pretty major app running under an older Zope that did everything through SQL methods: insert, update, delete, you name it. (I eventually had to move it off to a custom ZPublisher-based engine due to Zope's single-threaded, single-process nature at the time.)