Most of java-xml binding implementations provide two way
support.
i.e, serializing domain object to xml
deserializing xml to domain object.
But JLibs implementation is only
one way. that is "deserializing xml to domain object".
the main
advantages of JLibs implementation:
1. works with hand-coded domain
objects
most binding implementations mandate
that domain objects has to be generated
from schema or dtd.
They don't work with hand-coded domain objects
2. domain
objects are not tied to binding implementation
domain
objects dont need to extend/implement a particular class/interface from
binding implementation.
for example,
XMLBeans mandates that all domain objects
implement org.apache.xmlbeans.XmlObject
Similarly
EMF mandates that all domain objects implement EObject interface
3.
domain objects are light-weight. i.e not poluted with binding implementation
specific information
for example: the domain
objects created by XMLBeans or EMF carry lot of information which are
specific
to them. This will bloat up memory.
4. easier migration.
let us say in
version 2, you want to change the xml looks like, and still wants to provide
backward
compatibility to end-users.
This is tedious task with other binding frameworks. With
JLibs you can have different Binding implementations
for a
domain object and use appropriate one at runtime based on version of xml
document.
5. clear separation of binding and domain
object
6. in jlibs, it is like a callback methods. callback methods can
define when it has
to be called and what information from xml
document you want. You have complete control how to consume
that
information into domain object (because you are
implementing it in java code)
7. The runtime memory used
by jlibs binding is minimal and no reflection api is used
JLibs binding
implementation more of resembels apache-commons-digestor implementation but
without reflection
- Santhosh
On Mon, Jan 25, 2010 at 1:51 PM, Boris Kolpackov
<boris@codesynthesis.com>
wrote:
Hi Santhosh,
This idea might be new to Java, though
something like this has been
available for C++ for several years now (see
the C++/Parser[1]
mapping, for example).
I also think in your
architecture you miss one of the main reasons
why people choose to use
SAX over, say, DOM. Which is that they don't
want to (or cannot afford
to) build an in-memory representation.
Instead, the XML data is processed
as soon as it becomes available
in a pure event-driven or a partially
in-memory / partially event-
driven mode.
In this light, a
callback interface like this seems like a more
natural choice (using your
Employee example):
public interface Employee {
public
void name (String name);
public void age (int age);
public
void experience (int exp);
};
In the C++/Parser mapping I
mentioned above this interface as well
as the "SAX routing code" are
automatically generated from XML Schema.
The user can then implement
this interface to receive the data:
public class EmployeeImpl
implements Employee {
public void name (String
name)
{
// Handle
name.
}
public void age (int age)
{
// Handle age.
}
public void experience (int
exp)
{
// Handle
experience.
}
};
[1] http://www.codesynthesis.com/products/xsd/c++/parser/
Boris
--
Boris Kolpackov, Code Synthesis
http://codesynthesis.com/~boris/blog
Open-source XML
data binding for C++ http://codesynthesis.com/products/xsd
XML data binding
for embedded systems http://codesynthesis.com/products/xsde
Command line
interface to C++ compiler http://codesynthesis.com/projects/cli
