I follow your logic, yes. Javascript is a front-end. At this point, we are only prepared to spit out a client side, but some day we would have a server side. I think I see how to attack this approach, I'll take a run at it.
meanwhile, we're sending crossing email. > -----Original Message----- > From: James Mao [mailto:[EMAIL PROTECTED] > Sent: Monday, December 03, 2007 9:58 PM > To: [email protected] > Subject: Re: tools for javascript > > > > This thing generates javascript clients. It works with the existing > > frontends. All the generation code exists already in > rt/javascript. We > > could, I suppose, have a different generator for the pre-existing > > javascript front end, to assist people in writting > JavaScript \servers/. > > My brain hurts in terms of how we name these things > distinctly, since > > they have pretty nearly nothing to do with each other. > > > > I know, I just saw your another mail. > > But I'm still thinking the whole layout of the package, I'm > thinking of a new frontend for tools (e.g tools-js-frontend) > All the code gen related to the js, should go into the js > frontend. and the frontend can call the rt/js which you already done. > The wsdlto/core has a spec as well, which allows to load the > frontend, in verbose mode, it will print "Loading JaxWs frontend" > Which in JS case, should load the > "Loading JS frontend" > > Make sense? > > Right now, if you have a service running against the trunk > code, you > > can push in a URL like: > > > > http://host:port/Service?js > > > > and get back a JavaScript client. The momentary goal is to have the > > ability to do the same thing from command-line (or maven). > > > > Right, I understand that > > > So, it really is like wsdl generation except that it generates a > > different artifact. > > > > It also makes sense to have a wsdl2js command, by the same logic. > > > > Exactly, make no sense to re-invent the wheel :) > > James > > > > > > > >> -----Original Message----- > >> From: James Mao [mailto:[EMAIL PROTECTED] > >> Sent: Monday, December 03, 2007 9:42 PM > >> To: [email protected] > >> Subject: Re: tools for javascript > >> > >> WsdlTo actually is a framework, we have frontend plugin and > >> databinding plugin, we only have jaxws and jaxb for each, > >> > >> The wsdl2js, I guess it's a js frontend, right?, so we can > make it as > >> a plugin as well, and which databinding are you using? jaxb, or > >> aegis? > >> > >> The artifacts that you are going to generate can be defined as a > >> Velocity template > >> > >> All in all, wsdl2java will load wsdl file -> build wsdl4j > definition > >> model -> [validation] -> [customization] -> build service model -> > >> validation -> cxf java model -> generators > >> -> artifacts, That's how it works > >> > >> JavaTo is a little bit different, > >> > >> We support both simple frontend and jaxws frontend, we > will try to > >> detect the frontend from the class you provide, then we reused the > >> rt/core, to build the service from the java class, then we use the > >> Service2Wsdl builder to build the wsdl, of course, now we not just > >> generate the wsdl, we generate other stuff as well, like > the wrapper > >> bean classes etc. > >> > >> For the CLI, we used the code donated from IONA, which > called xsume, > >> it use the xml file to define the arguments/options etc. > >> > >> I would like to hear from you, about the plan, is it target to cxf > >> 2.1? > >> or later > >> > >> I'm working on jaxws 2.1 stuff at moment, so probably will not > >> involve that much before 2.1, but i would like someone can try the > >> tools framework, That would very helpful to make the api more > >> flexible > >> > >> Regards, > >> James > >> > >> > >> > >>> It is time to create wsdl2js and java2js. I confess that I > >>> > >> am daunted > >> > >>> by the task of starting this from zero. Is there any > >>> > >> possibilies that > >> > >>> the tool-experts would be willing to create some shells for me? > >>> > >>> > >>> > >>> > >> > > > > > > > >
