James, The original code we donated was a wsdl2js tool. That tool disolved as I reimplemented its core as code in the rt/javascript project. That new code in there can generate a Javascript client based on a service model.
In the rest of CXF, we have code to make service models from WSDL and from Java. While the ?js URL is a great idea, my feeling is that we need to also provide tools (command-line and Maven) for these tasks. I am not very sure of the appropriate modularity. On the javato side, I can see that this could fit into the existing implementation of java2ws pretty easily. Would we just add a -javascript argument to that tool? Personally, I would prefer to have it be a separate command line, even if it shared 99% of the code with the existing tool. However, that is not a very well-developed preference, and if everyone else prefers to just add syntax to java2ws, I will go there. I haven't look at wsdl2java, but I believe that it's a very thin layer on the JAX-WS/JAXB RI. So I'm not sure how much sharing makes sense in that case. As for the wsdl extension, I would like to support a CXF-defined namespace to carry some javascript-specific information around in the wsdl. I think it would live at the level of a service. It would make sense to worry about this \last/. --benson > -----Original Message----- > From: James Mao [mailto:[EMAIL PROTECTED] > Sent: Monday, December 03, 2007 9:51 PM > To: [email protected] > Subject: Re: tools for javascript > > Oh, hit 'send' too quickly, > > > > All the code generation is done. You can invoke it > currently with the > > ?js URL. > > > > Is it wsdl2js? > That's a good thing, we can reuse the rt/js part in code generation > > > 'All' I need to add is the command-line 'dump it to a file' in > > addition to the live URL handling. > > > > You can have your own Generator, it is OK not using the > velocity templates, you can dump them directly, not a big deal > > > I also have a yen to add some a new wsdl extension for the > case where > > someone explicitly controls the mapping from URI to > javascript prefix. > > > > Not quite understand this part, but we handle the wsdl > extesions as a plugin as well, like the wsdl:port is an > extension plugin, so we can handle the port:address equally > > James > > > > >> -----Original Message----- > >> From: Glen Mazza [mailto:[EMAIL PROTECTED] > >> Sent: Monday, December 03, 2007 3:35 PM > >> To: [email protected] > >> Subject: Re: tools for javascript > >> > >> Ouch, that doesn't sound like fun. But I would start with > wsdl2js, > >> look at the wsdl2java Java output velocity templates, and just > >> re-edit those to output JavaScript instead. > >> > >> Next, during testing, I guess, see where that such a > 1-to-1 mapping > >> will > >> *not* work, and what workarounds you can create for that. > >> > >> However, I don't know what you're going to do for the JAXB-created > >> classes (in the wsdl:types section). We don't have templates for > >> those. > >> > >> Glen > >> > >> > >> Am Montag, den 03.12.2007, 14:18 -0500 schrieb Benson Margulies: > >> > >>> 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? > >>> > >> > >> > > > > > > > >
