Hi Anne,
The discussion we've been having relates to how wrapping/unwrapping is
handled in the code. What Sanjiva and Ajith appear to be saying is that
each parameter element should be a separate class, while I want to use
an approach that's closer to Axis(1) wrapped handling, where primitives
and simple values are handled directly and only complex structures need
class definitions.
- Dennis
Anne Thomas Manes wrote:
Dennis,
The terminology is confusing.
When using Document style, the message body on the wire must always
contain at most one element. When using "non-wrapped" document style,
the databinding maps that body element to a value object. When using
"wrapped" style, that body element (which has the same name as the
operation) is a wrapper around a set of parameter elements.
"Unwrapping" refers to the process in which the databinding system
automatically unwraps the body element and maps the parameter elements
to individual classes. Support for "wrapped" style (which includes the
ability to automatically "unwrap" the body wrapper element) is what
Ajith is currently implementing.
Anne
On 6/24/06, *Dennis Sosnoski* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
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]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
