James, Your analysis of the current architecture is correct.
The way we use this today is this: from a web page, you include the two generated JavaScript files plus some utilities which I'll post soon. To talk to the service, the user's code has to create one or more objects and set their properties, and then start the interaction with the server. The user supplies functions to be called on a successful response or an error. If we generate the code dynamically, as per your and Dan's suggestion, we'll emit all of that code all at once. I would offer a caveat: when developing an application of this, the programmer needs to stare at the generated JavaScript to see what the protocol is. And a single web application might be talking to more than one service, so defining the common utilities over-and-over might not be entirely desirable. Just as you can either use the ?wsdl URL to obtain WSDL, or you can run java2wsdl, I'd recommend supporting both a command-line javascript emitter and also the fully dynamic scheme. This would also have the effect of retaining some usefulness for people who want to talk to a non-CXF service. > -----Original Message----- > From: James Mao [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 19, 2007 11:54 PM > To: [email protected] > Subject: Re: Contribution of wsdl2js tool > > Hi Benson, > > Excellent job, Just go through the code, really great. > > So, to be more specific, the wsdl2js is about turn the wsdl1.1 wsdl > (through wsdl4j) to a js soap client which can be embed in the browser, > right? > or at least that's the current status. > > One question, how you deploy those generated artifacts? > > As Dan metioned, is it possible to use url like this > http://localhost/fooService?js to get the artifacts, > I saw normally you will generate two js files, one for the types, > another for the protocol > If that's what we will do, then the code will go into the CXF runtime, > we don't need the wsdl2js command line tools any more > (Or we still need the command line tools, because people maybe use other > service framework, and just want the cxf command line tools to generate > js artifacts) > > Here is just a FYI, > > In CXF wsdlto framework, we will first turn the wsdl file to wsdl > definition (through wsdl4j) , then we will customize the wsdl defintion > in case of jaxws (jaxws binding files etc.) > and then we turn the wsdl definition to cxf service model (which will > support both the wsdl1.1 and wsdl2.0) > The service model will be further processed by a chain of processors, > and turn into the CXF java model (in case of wsdl2java), > The generated java model will then give to bunch of generators, which > will generate the final artifacts (velocity template based) > > > So, in case of wsdl2js, i think what we need to do is just port the js > model you have, reuse the Translator you have and turn it to a > processor, and then write some generators and templates, > > I'm thinking of adding a new tools frontend plugin (hope not) or just > some processors/generators for the tools jaxws frontend? > > Regards, > James > > > > > Hi Benson, > > > > Thanks for taking the initial steps with this contribution (and for your > > other unit test contributions so far). > > > > I've taken an initial look through the code and wanted to relay some > > thoughts. First, I like the way you've done this. Its simple - I was > > trying > > to do something way more complicated back in the day and I think this > > way is > > probably much better :-). I have yet to try it out on any actual > services > > though ;-) > > > > My next thought is that if we're going to accept this contribution, we > > would > > need to get it inside our build. We can help give you guidance on this. > > Basically we just need to get it Mavenized, in the standard directory > > layout, set up with the appropriate Apache license headers, conforming > to > > our Checkstyle/PMD rules, etc. > > > > Lastly, I think it'd be really cool if we hooked this into CXF such that > > someone could call http://localhost/fooService?js and get out a > > javascript > > client. CXF has a QueryHandler interface which we can implement to do > > this. > > That is how ?wsdl is supported as well. > > > > Cheers, > > - Dan > > > > On 7/19/07, Benson Margulies <[EMAIL PROTECTED]> wrote: > >> > >> OK, time to join the dev list. Will do. > >> > >> > -----Original Message----- > >> > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > >> > Sent: Thursday, July 19, 2007 11:29 AM > >> > To: [EMAIL PROTECTED] > >> > Subject: Re: Contribution of wsdl2js tool > >> > > >> > Hi Benson, > >> > > >> > Such contributions are definitely welcome! > >> > > >> > I believe there are a few major things that need to happen. You would > >> need > >> > to package the code under an ASL license and send along Corporate CLA > >> [1]. > >> > The CXF community would also need to vote on the contribution and > >> possible > >> > committers. There may also be some incubator related things we need > to > >> do. > >> > I'll do some digging and will report back with more info. > >> > > >> > Also, it might be good to redirect this discussion to the dev list. > >> > > >> > Cheers, > >> > - Dan > >> > > >> > 1. http://www.apache.org/licenses/#clas > >> > > >> > On 7/19/07, Benson Margulies <[EMAIL PROTECTED]> wrote: > >> > > > >> > > Dear CXF team, > >> > > > >> > > > >> > > > >> > > Basis Technology would like to contribute our wsdl2js tool to CXF > >> under > >> > > the usual ASF license. > >> > > > >> > > > >> > > > >> > > The tool consists of Java source code that uses the same WSDL > >> library > >> > > that CXF already uses and generates Javascript code that targets > >> some > >> > > JavaScript utility functions that work in Firefox and IE (and > >> probably > >> > > others). > >> > > > >> > > > >> > > > >> > > What is the mechanics of this process? I could tar up the whole > >> business > >> > > and append it to a JIRA. You could consider accepting me as a > >> committer. > >> > > You could ask me to post it for review some other way. > >> > > > >> > > > >> > > > >> > > --benson > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > -- > >> > Dan Diephouse > >> > Envoi Solutions > >> > http://envoisolutions.com | http://netzooid.com/blog > >> > > > > > >
