<br><br><div><span class="gmail_quote">On 6/3/07, <b class="gmail_sendername">Geoff Crawford</b> <<a href="mailto:geoff@innov8cs.com">geoff@innov8cs.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 10:35 AM 6/2/2007, John Sundman wrote:<br><br>>Second, as of 4.0.2 the XML-RPC APIs now work in both DHTML and SWF<br>>runtimes in SOLO mode -- no LPS required.<br>><br><br>Thanks for that!<br><br>Sounds like you might be the right person to ask a couple
<br>of questions on RPC - particularly SOAP.<br><br>Any chance the SOAP will also be available to SOLO any<br>time soon?</blockquote><div><br><br>Hi, I'm doing the most current work on the RPC libraries in the SWF and DHTML runtimes.
<br>There are a bunch of good issues you've raised, I'll try to address some of them<br>and give an overview of what the plans are. I cc'd this discussion to Laszlo-Dev as well. <br><br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm currently working on some SOAP calls, which unfortunately<br>the system is not following the WSDL and the name spacing<br>is off.<br><br>Ways I've thought of getting around it are:<br><br>1. just going to some plain XMLHttpRequest code - are you aware
<br>the DHTML version of XMLHttpRequest is broken? I'm playing in<br>SWF and working code complains about using lz.XMLHttpRequest<br>because it's duplicating the name?? I can give you details<br>and file a bug report if need be.
</blockquote><div><br>Please file a bug report, thanks!<br><br>The SWF implementation of XMLHTTPRequest was just a simple wrapper around<br>the standard data loading API, to make AJAX programmers feel more at home. <br>That was put in long before we started implementing the DHTML runtime. Now that we have DHTML, we need to figure out how to reconcile this. I'd like to leave the native
<br>DHTML XMLHTTPRequest, and rename the pseudo-XMLHTTPRequest class that is in SWF, or at least make people use the 'lz' prefix, so there is no warning or shadowing <br>going on. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2. I have to do 3 calls instead of one to get my XML dataset,<br>otherwise I could fudge my own XML to the datatset's loading<br>of the data. So I ruled that out.<br><br>3. I looked heavily at the dhtml (and SWF versions too) of
<br>rpc.js, namespace.js, and soap.js. I thought I saw some<br>serialize routines that were creating the XML in namespace.js,<br>but changing that code didn't affect the XML generated in<br>the SOAP request. I can sort of see where some of the values
<br>used in the SOAP envelope are being created, but not the actual<br>XML body. I'm thinking it builds some kind of prototypical<br>XML at time of loading the WSDL. If you could direct me to<br>where that code is, I'd be happy to make some corrections.
<br><br>4. Because my issue is with name spacing, I was thinking I<br>might also be able to just change the name space lookup table<br>to make it work. Unfortunately I can't see to track down where<br>it applies that table in order to know what changes in the
<br>table would produce the right name space. Basically the<br>WSDL calls for each request to have a name space value on<br>the body that is equal to the domain default plus ":" and<br>the port name. The SOAP implementation ignores the WSDL's
<br>definition of the message it should build and uses a<br>single value all the time that came from the WSDL:Definition<br>section. (I can confirm that because I mess with my<br>WSDL and see that changing in the SOAP request)
<br><br>5. Maybe if I someone could also point me to where the<br>XML is being sent out, I could do a quick transformation<br>on the one attribute of the one node in question. How<br>can I get access to what SOAP is sending out just before
<br>the actual XMLHttpRequest is invoked?<br><br>OK so I'm going to push my luck here, and also ask if<br>there isn't a way to share my WSDL between two different<br>SOAP instances? What I'd really love to see is the
<br>WSDL= be able to be set to a dataset instead of always<br>being a URL. I'm working on ERP systems - there are<br>lots and lots of ports, and multiple operations in<br>each of the ports. Have you noticed the WSDL load
<br>is actually quite a bit slower than loading the same<br>document into a dataset? (not to mention the issues<br>of async calls when you have 19 calls to the exact<br>same WSDL document) I have ideas about what that<br>
code should look like, but don't know enough of<br>where to start.<br><br>Thanks for listening anyway. ;-)</blockquote><div><br>I'll post a separate message to laszlo-dev which outlines how the current system works.
<br>Briefly, it does do some XML serialization on the client to format the SOAP request. <br>Then the message is passed to the server, which relies on the apache axis library on the server to implement the SOAP transaction with the back-end, and then that response is encoded as SWF byte code (for Flash) or JSON (for DHTML) and sent back to the client.
<br>Some namespace issues may better be dealt with on the server end than on the client.<br><br>What I'd really like to see is an implementation of the SOAP protocol entirely in Javascript, that could be ported to LZX. That would get the LPS server and Apache-axis out of the loop entirely. This would allow SOLO apps to be SOAP clients. (And I'd like to do that with XMLRPC as well, which should be an order of magnitude easier than the SOAP client implementation).
<br><br>I've been looking around to see if anyone has implemented an<br>open source SOAP client in Javascript, but so far haven't found anything that is even close to compliant with the spec. I'd be interested if you know of anything that looks promising
<br>in that area?<br><br>The LPS server is currently using a fairly old version of the apache axis and related utility libraries. There are some SOAP bugs that may be fixed by moving to a more recent apache axis and related utility libraries, but the apache APIs have drifted a lot, so this is not trivial.
<br><br><br><br> </div><br></div><br><br clear="all"><br>-- <br>Henry Minsky<br>Software Architect<br><a href="mailto:hminsky@laszlosystems.com">hminsky@laszlosystems.com</a><br><br>