Copying this to jibx-user, where we really should continue the
discussion if you'd like to go further.
Dan Diephouse wrote:
Dennis Sosnoski wrote:
Dan Diephouse wrote:
Dennis Sosnoski wrote:
...
There are other problems lurking in the wings from the standard
schemas approach, too. Schema versioning is not well handled by any
of the existing frameworks that I'm aware of, though JAXB 2.0 is
moving in this direction. Right now the schema-centric frameworks
require you to generate a new set of classes for each version of
the schema you want to support. I don't think that's a practical
solution, given the trend toward industry-wide schemas being
updated every year or two. In a way this becomes a variation of
start-from-Java, even if the Java you're starting from was
generated from version 1.0 of the schema and you just want to work
with version 1.1.
I totally agree on the schema-> is very similar to the start from
java case. In each case you're still using a DTO pattern. What do
you see as alternatives to this approach?
The only alternative I know of is some form of mapped binding, where
you use a binding definition to establish the relationships between
your Java classes and XML. In the case of JiBX you can use multiple
binding definitions with the same Java classes, so you're able to
reuse your existing classes for different schema versions. That
doesn't mean the classes don't have to change at all - you'd still
need to add fields or new classes for new components from the schema
- but you should be able to continue using the modified classes with
different versions of the schema, selecting at runtime which binding
to use for a particular input document.
I knew JiBX had some of that capability. This may be a bit off topic,
but take this example: at first I'm receiving an xsd:double
representing a price, then I create a complex type which holds both
the amount and the currency units. Can JiBX take my xsd:double, create
a new price class with the default currency unit instead of just
passing me a double?
I can think of at least three simple ways of handling this using JiBX.
Here's your original case:
<price>12.99</price> <-> private float m_price;
Binding: <value name="price" field="m_price"/>
Here's the expanded version:
<price units="USD">12.99</price> <-> private CurrencyAmount m_price;
public class CurrencyAmount {
private String m_units;
private float m_amount;
...
}
Binding: <structure name="price" field="m_price">
<value name="units" style="attribute" field="m_units"/>
<value style="text" field="m_amount"/>
</structure>
You could (1) set the default currency unit directly in the
CurrencyAmount constructor, then just use normal JiBX binding features
for everything. This would change your binding for the old-style
documents to (as the clearest alternative):
Binding: <structure field="m_price">
<value name="price" field="m_amount"/>
</structure>
(2) you could use a factory method for the first case which just sets
the default currency. This would be along the lines of:
public class CurrencyAmount {
...
public static CurrencyAmount newDefaultInstance() {
CurrencyAmount inst = new CurrencyAmount();
inst.m_units = "USD";
return inst;
}
}
Binding: <structure field="m_price"
factory="CurrencyAmount.newDefaultInstance">
<value name="price" field="m_amount"/>
</structure>
(3) you could just use the new binding for old documents as well, making
the units attribute optional but defaulting to your old assumed value:
Binding: <structure name="price" field="m_price">
<value name="units" style="attribute" field="m_units"
usage="optional" default="USD"/>
<value style="text" field="m_amount"/>
</structure>
TIBCO did a cool thing which allowed you to map arbitrary classes to
arbitrary schema elements that I saw here (watch the screencast, ~5
minutes in):
http://weblog.infoworld.com/udell/2005/05/25.html
I don't know if others are, but I'd be interested in putting together
some sort of object/schema relationship designer that allowed you to
specify these relationships easily.
Doesn't play for me, but sounds like the type of thing I'd love to have
work with JiBX. Want to join the JiBX project?
- Dennis
