Dan Diephouse wrote:
Dennis Sosnoski wrote:
While we have a number of tools for generating Java object models to
(more or less) match a schema, most of these tools either cannot work
with pre-existing Java classes or can only work with existing classes
using their own built-in correspondences.
...
Agreed. I would add that I see that this is a problem with nearly all
approaches. Even when parsing the XML by hand, you need to have
seperate code for each version unless you're doing transformations.
DTOs are generally the same way.
I don't view the DTO layer as necessarily a bad thing. If you're
schema and internal API are a lot different (which they often are), it
can make translation a lot easier. And it'd still be nice to map
multiple schemas to one set of DTOs.
JiBX can actually handle both these cases directly (direct binding to
business model objects without the use of DTOs, and multiple schemas to
a single set of objects). The binding definitions effectively serve the
same purpose as transfer code or XSLT transformations (within limits).
Of course, this creates the need to maintain the binding definitions -
hence my interest in a tool of the type we're discussing.
... I can certainly see the benefits to providing a tool that allows
an interactive approach to building a JiBX binding, basically
starting with Betwixt-like defaults and allowing overrides at every
step of the way down to a detailed JiBX binding. The way I envision
it this should show sample XML output (or the current schema, for
those developers able to understand schemas) at every step of the way
- when you change the binding, you immediately get the change
reflected in the schema/sample XML. Ideally you should even be able
to go the other way - modify the schema, and have the binding
automatically reflect the change (or replace the schema with a new
version, and have the binding adjust as best it can and then flag the
mismatches).
...
To clarify the use cases:
1. Schema exists, but no java code
2. Java code exists, but no schema
3. Both schema and java exist.
How do we map between them, even when there is very little correlation
betwen java and schema. Each one is pretty important I think.
I see something a bit different then Dennis. (now where is my virtual
white board....) On the left pane I would see a structural
representation of the schema portions. In the middle is a place to
apply "actions" to a chunk of schema. On the right I would see a list
of actions. Actions would be "create object," "set property," or even
"run this piece of java code (via janino, groovy or the like)".
Say I have a schema like so:
<xsd:complexType name="book">
<xsd:sequence>
<xsd:element name="author" type="xsd:string"/>
<xsd:element name="title" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
I'd see this on the left (with the option to view the schema source)
+ book
|- author
|- title
When I selected book I would see the middle pane pop up with different
events like "on start of tag", "on end of tag", or on body. I'd be
able to drag in different actions from the right to certain events and
customize them. So on book I'd drag in "create object" and specify the
"Book" object. On the author element I'd want to do a set property. It
would also be intelligent enough create a mapping for a POJO
automatically if it can.
I like that idea a lot!
...
Much of the off-list discussion has revolved around the possibility
of building a generic tool of this type, one able to work with
different frameworks. On thinking it over, it seems to me that at
least the general framework of the tool should be reusable - say the
IDE integration and XML/schema display and manipulation. That would
leave the need to write plugins for each binding framework to handle
XML instance and schema generation from a binding and set of classes,
and to handle editing the actual binding definition (in whatever form
that takes - an XML file for Betwixt and JiBX, annotations for JAXB,
etc.).
The version I described above is probably pretty binding toolkit
specific :-), but I'm open to anything really.
I'm confused aobut how JAXB can be used to handle multiple versions.
You can't really annotate a java class for multiple versions afterall.
That's true, but JAXB could still use a tool like this within its single
schema limit, while frameworks that support multiple mappings could go
further.
What do people think of this? Anyone want to jump right in and start
putting this together? ;-)
I definitely would like to spend some time working on this next week.
Although I want to hear more ideas as there are many bright people
hanging around...
One other possible solution I just thought of is Dozer (maybe this
should go in a seperate thread). Dozer (http://dozer.sf.net) could be
used to map multiple sets of DTOs which are generated from a schema to
a single set of objects. This seems like a lot of work though.
That's an interesting possibility, especially for making a
schema-centric framework like XMLBeans more Java-friendly.
- Dennis
