I think I generally agree that there's some awkwardness in handling of
elements and types --- like you said, you shouldn't need to use
ElementWrapper and there got to be a better way to handle them.
But I hope you understand this is not an easy problem.
For example, I don't think your proposal would work.
> Foo {
> A getA();
> B getB();
> setA(T);
> setB(T);
> }
You are setting T and getting A. So the implementation of Foo needs to
create a new instance of A whenever a new T is set. Now is that what you
really want?
Let's just completely forget about XML for a second and do you write
code like this --- where the getter and setter is asymmetric?
And in general,
> A {
> T getType();
> }
> B {
> T getType();
> }
this would make it more tedious to write client code since now you have
to write "getType()" all the time to access its content.
But in my personal opinion, allowing a binding like this by an explicit
customization would be conceivable and I hope that solves your problem.
If you want to marshal T, you could:
A a = objectFactory.createA();
a.setType(t);
marshal(a);
> Will ElementWrapper become the standard way to obtain a real Element ?
> If so, will it be part of the standard interface (not implementation-specific) ?
I have no idea if it will become a standard way (I doubt), but if it
does, it surely has to be a part of the standard interface.
regards,
--
Kohsuke KAWAGUCHI 408-276-7063 (x17063)
Sun Microsystems kohsuke.kawaguchi_at_sun.com