Hi Ajith,
Thanks for giving us some insights into your changes. Comments inline.
Ajith Ranabahu wrote:
I've been doing some more work on the JiBX version of this, mainly
working on the message receiver side. One approach that would let us
keep the current method-based code generation for the data binding
templates is to just have the invokeBusinessLogic() method generated by
the message receiver template call a method based on the operation name
to handle the actual business logic call. We could add a per-operation
flag for the data binding extension to indicate whether it wants to
handle the operation in this manner, as opposed to the current approach.
Hmm... this is not really strightforward. You would not need to know
whether there are two levels of skeletons and it seems slightly
confusing even to implement.
I don't see it as that complex. Basically there's just a flag for each
operation set by the data binding extension, and if the flag is set the
message receiver template skips generating the code to call the service
method and instead calls the wrapper method (which is then generated by
the data binding extension). This is essentially very similar to what is
done currently with the toOM and fromOM method generation, but just
letting the data binding handle the entire service method invocation.
...
let me describe what I've done so far.
There is a codegen extension called schemaUnwrappingExtension that
looks at the elements refered by the messages and tries to find what
are the parameters involved. The original schemas never change but the
information found is added to a special container and hanged at the
relevant AxisMessage. I've done this part and slightly modified the
emitter also.
I've said before how for the JiBX handling I really want to control the
unwrapping in the data binding extension code, rather than use a generic
approach. As long as it's still possible for me to do that and overwrite
what's been done by the schemaUnwrappingExtension there shouldn't be any
problem with me implementing my changes.
When it comes to the databinders, the extra task they have to do is to
populate the typemap for the references of the unwrapped parts.
Certain databinders like XMLBeans has no problem in this since it
generates classes for all the element references, even for the
internal ones. I can modify ADB to do this and I suppose jibX can also
do a similar thing.
One of the points of unwrapping is supposed to be to reduce the number
of class generated. Besides, in many cases those unwrapped parts are
going to be primitives. How do you plan to handle these?
Once the databinders are done the templates need to change to
concatanate the multiple arguments (or to expand them). This need to
be incorporated into the templates properly and code should be
generated to concatenate the arguments and build a single OMElement as
required (or the other way). Note that this code is databinding
specific and needs to go inisde the databinding templates.
What I think is that we can find a failry generic method for
unwrapping just like what we did for multiple databindings.
I'm not sure I understand what you're saying here. The method-based
approach that I outlined was intended to allow a single OMElement to be
passed off and another returned, with all the details of translating
that element and calling the service code handled by the data binding
code generation. It sounds like you're talking about doing the same
thing inline. That's the approach I started with, before deciding the
XSLT code generation would be much simpler if there's a separate method
to handle this for each operation.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
