Sanjiva Weerawarana wrote:
On Fri, 2006-06-23 at 22:03 +1200, Dennis Sosnoski wrote:
...
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?

Reduce the # of classes? Unwrapping *increases* the number of classes ..
each arg becomes a separate class. I must be missing something.
I think that's the crux of where my approach differs from what Ajith is implementing. You're thinking in terms of a unique class per element name, which leads to an even worse proliferations of unnecessary classes than what we've got now. The reason I want to handle the entire call to the service method within the data binding-specific code is so that I can work with primitives and classes that have a defined structure binding (the equivalent of a complexType definition) but may be reused in different places with different names. That way you're working only with the actual data classes, without the wrapper classes.

Here's a snippet from the Axis(1) users guide, describing the Axis(1) handling of wrapped vs. unwrapped:

For a *document* style service, this would map to a method like this:

public void method(PurchaseOrder po)

In other words, the ENTIRE <PurchaseOrder> element would be handed to your method as a single bean with three fields inside it. On the other hand, for a *wrapped* style service, it would map to a method like this:

public void purchaseOrder(String item, int quantity, String description)

Note that in the "wrapped" case, the <PurchaseOrder> element is a "wrapper" (hence the name) which only serves to indicate the correct operation. The arguments to our method are what we find when we "unwrap" the outer element and take each of the inner ones as a parameter.

This is what users expect from unwrapped support, not to have to deal with a whole new layer of classes wrapping the simple bean values.

 - Dennis

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to