Yes, this works with either an interface or an abstract class as the
base type.
On the substitution group issue, it was interesting to see that despite
claims of 100% schema compatibility XMLBeans doesn't even try to handle
these in Java terms. It seems like the extends="..." approach will work
fine for matching substitution groups up with Java inheritance once it's
extended to multiple levels.
- Dennis
Eitan Suez wrote:
i haven't verified this yet but does your suggested solution
apply both to abstract classes and interfaces?
(i was referring specifically to two classes that both implement a
specific interface.)
in other words, can i used abstract mappings to model the latter,
or do i have to use abstract classes?
yes, it's interesting to see how the xml side of
this is analogous to xml schema substitution groups.
thanks, eitan
On Tue, 2005-08-16 at 11:32 -0700, Dennis Sosnoski wrote:
Assuming you want to use a common binding for I your best way of
handling this is by using a <mapping abstract="true" ...> for I, and
<mapping extends="I" ...> mappings for A and B. That way the x reference
to I will accept either of the two extensions. This is the limited
equivalent of a schema substitution group (limited because the 1.0 code
supports only one level of extends).
- Dennis
Eitan Suez wrote:
hi all,
given a simple interface modeling scenario where
class A and class B implement interface I, and
finally where class C has a property, x, of type
I. how does one model this in jibx?
in my mapping file i know i'll be specifying
a mapping for A, B, and C (including C's property,
x). but the problem is that when jibx tries to
marshal/unmarshal C it knows nothing about the
interface type.
am i overlooking something?
i solved the problem by writing an "InterfaceMapper"
whose gist is in these two methods:
public void marshal(Object obj, IMarshallingContext ictx)
throws JiBXException
{
((IMarshallable) obj).marshal(ictx);
}
public Object unmarshal(Object obj, IUnmarshallingContext ictx)
throws JiBXException
{
return ictx.unmarshalElement();
}
that is, any time you try to marshal x, it will always be of type
A or B and they're both marshallable. when it's time to unmarshal,
all the information is there for jibx to simply do its job (to know
which concrete implementation of I has been marshalled).
the only thing i'm not doing here (which is important) is verifying
that:
a. the type of the unmarshalled element is mapped
b. the type of the unmarshalled element is an instance of I
i'm hoping that there's already a way to do this in jibx without a
customer marshaller. if not, then i think something like the above
might be useful to include in/add to jibx.
thanks, eitan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jibx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-users
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jibx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-users
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jibx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-users
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jibx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-users
