Moving toward better compatibility with the monstrosity of schema is not something I relish, but it seems unavoidable. My intent is to be able to handle as much of schema as possible while continuing to allow more flexibility than schema provides in many areas. I *do* want to make sure I don't prevent compatibility with RelaxNG or other alternatives, though, so I'm hoping you can help out there - you seem to have a good understanding of RNG, does it sound like these changes will break compatibility there? Or, are there RNG concepts that cannot currently be represented in JiBX?
BTW, now that I look again at your original question I see that it wasn't what I answered. :-[ If you want to restrict the items in the collection to classes implementing a particular interface, you should be able to do that now by defining an abstract <mapping> for the interface, then defining concrete <mapping>s for the implementation classes that extend the abstract interface <mapping>. This works like a substitution group, in schema terms, where each extension of the base definition has a distinct element name (though JiBX provides more flexibility than the schema construct, which requires that the information from the head element comes first within the structure of the derived elements). Using a single element name with different types (type substitution) is not possible until beta 4 (unless you want to implement this with a custom mar/umar). Currently the substitution group support is limited to a single level of substitution; I'll also be eliminating this restriction in beta 4.
- Dennis
Eitan Suez wrote:
sounds good. i recall castor embedding xsi:type when marshalling and using that in the reverse direction to figure out which type to instantiate.
/ eitan
On Feb 11, 2005, at 10:59 PM, Dennis Sosnoski wrote:
Hi Eitan,
You can actually handle this now by using a factory-method for the instances of the interface. I've got an example of that in the beta 3d code with a simple factory method to create an ArrayList. Whenever a List is being mapped, you can then just specify the factory-method and have a specific type created at runtime.
It'd be nice to have this happen automatically, so that you just make a particular factory-method the default for a particular type. That's something I'll have to think about.
- Dennis
Eitan Suez wrote:
hello,
i was curious as to the extent of "interface" support in jibx.
i wrote a little test program that shows how jibx can handle the polymorphic situation of a collection of items whose type adheres to a specific interface.
marshalling and unmarshalling work fine, by virtue of the
fact that collections are not restricted to an item type. however,
one cannot actually ask jibx to enforce the item-type to match
an interface. jibx complains about the fact that it cannot find
a no-argument constructor for the interface: it expects the item-type
to be a concrete class.
dennis, are there any issues related to handling interfaces that you consider important enough and plan to address in future versions?
thanks, eitan
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ jibx-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jibx-users
