I've had some offline chats with Venkat about this. I'd not ported any of
the E4X code over from M1 so Venkat is looking at that. The XML instance
utility being talked about is for JIRA TUSCANY-419. Here's a bit more detail
on TUSCANY-419 and how it would work.

Today an E4X helloworld function looks like this:

function getGreeting(xmlIn) {
  var greeting = "e4xHello " + xmlIn..*::in0;
  var xmlOut =
     <helloworld:getGreetingsResponse xmlns:helloworld="
http://integration.rhino.container.tuscany.apache.org";>
         <helloworld:getGreetingsReturn> { greeting }
</helloworld:getGreetingsReturn>
     </helloworld:getGreetingsResponse>;
  return xmlOut;
}

There's a lot of boilerplate XML in there which could be determined
automatically from the WSDL, so ideally the function could rewritten
something like:

function getGreeting(xmlIn) {
  var xmlOut = _getXML("getGreetingResponse");
  xmlOut.getGreetingsReturn = "e4xHello " + xmlIn..*::in0;
  return xmlOut;
}

The _getResponseXML function is a system supplied function that the
JavaScript container injects into the script environment. It returns an E4X
XML object that is an representation of the WSDL schema with all the values
defaulting.  Thats worked out based on the interface of the component, there
could be similar ones for references, eg, if there is a reference named foo
you could do foo._getXML("fooType").

  ...ant

On 8/20/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

Hi Ant,

Is this something that works in M2 now?  I remember doing a util for
creating xml instances for this.

When I see the current trunk's javascript container I don't see the e4x
samples.  Shall I try moving them over and intergrating with the xml
instance creation utility.  Please let me know.

Thanks.

- Venkat

On 6/7/06, ant elder <[EMAIL PROTECTED]> wrote:
>
> No reply to this yet...after a little playing around it seems to work so
> I'm
> going to go ahead unless anyone raises any objections now. Sebastien,
you
> did the async work using PolicyBuilders and Interceptors so have you any
> comments to what I suggested in the email below?
>
>    ...ant
>
> On 6/6/06, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > I wondered about using Tuscany PolicyBuilders and Interceptors to help
> > with E4X support for the work required in TUSCANY-418, TUSCANY-419,
and
> > TUSCANY-420. Right now the E4X code isn't so elegant with the way it
> works
> > out when and how to convert the Java objects in a message into E4X
XML,
> and
> > with the current code i can't get E4X XML as parameters on reference
> > invocations working.
> >
> > Looking at how the code for async works, it seems like for E4X support
> > there could be source and target policy builders that look at the
wires
> and
> > when required (*) insert an interceptor that converts the message
> objects
> > from/to XmlObjects, and then the JavaScript container would simply
> always
> > convert XmlObjects from/to E4X XML objects.
> >
> > (*) the when required would be something like when the wire target is
a
> > JavaScript component with interface described by a WSDL portType, or a
> wire
> > source is a JavaScript component and the wire target has an interface
> > described with WSDL.
> >
> > Does this sound like a reasonable use of PolicyBuilders and
> Interceptors?
> > It seems like something like this may also be a step on the way to the
> > efficient streaming of messages in TUSCANY-104?
> >
> >    ...ant
> >
> >
> >
> >
> >
>
>


Reply via email to