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.
We used to have a java2/core before, it was designed to have that.
anyway, that's another story.
I'm OK to just add the js stuff into the java2ws for now, but we have to
remember that if things growing, we have to split it, that make things
more clear.
The shell scripts? definitely should have separate scripts
I bet we're actually agreed on that.
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?
