Hi Dennis and all, I'm very sorry if I made this explanation late. I owe an explanation of the recent commits I've done regarding unwrapping. Please find my comments inlined and I've described what I have done so far also.
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.
So if the flag isn't set, the current approach is used, with toOM and fromOM methods generated by the data binding. If the flag is set, the data binding would need to instead generate invokeAddOperation, invokeSubtraceOperation, etc. The latter methods would take an OMElement as a parameter and return another, handling the whole conversion directly. The flag for using this unwrapped handling would need to be set by the data binding extension code for each operation it wanted to handle, and it would need to pass information to be included in the XML document generated as input to the message receiver template. I've been passing information in my code using the pre-existing trick of storing an element in the type mapping, rather than a String class name, but this is somewhat limited. It'd be better to have a cleaner way of passing information for the XML document, including the flags for which operations should be unwrapped. If some of the data binding frameworks want to just simplify the schema for code generation, and use custom conversions only for complex structures, it'd be easy enough to have common code support code for this in a utility class. It'd also be easy to include any common transformation templates in the basic MessageReceiverTemplate.xsl, where they can be invoked by name from the data binding framework-specific template. That way the frameworks that just want the basic handling don't have much added complexity. How does this sound to you, Ajith?
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. 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. 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.
- Dennis
-- Ajith Ranabahu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
