incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <>
Subject Re: [jcr-mapping] persistence of the mapping model
Date Thu, 04 Aug 2005 22:03:21 GMT

>No - Let me resume why I'm agains tools like XmlBeans, JAXB, ... and
>XML schema :
>* Thoses tools are generating java classes and sometime it is
>difficult to change the class object structure. We will have a few
>number of java classes to read the config file. So write by hand
>thoses classes is not a big deal. Futhermore, using a pre-processing
>in order to just read a simple config file is a little bit heavy - no
>:-) ?
>* The mapping file should be very simple - I hope it will be otherwise
>the framework will not be used :-). So, a simple DTD is sufficiant.
>Xml schema becomes interesting for more complex grammar. See
>Jackrabbit, Hibernante, OJB, ... all these frameworks are using very
>simple DTD.
>* We need to read the mapping file and cache it in memory (in an
>object graph). So, Digester is (for me) one of the best tools to do
>it. Others framework become interesting when your update the xml file
>* See
>Give 2 days, I hope to commit a small example (before my upcoming vacations). 
Hello Christophe,

the general advantage I see is, that you can have a better error 
handling in comparison to a DTD.
In my opinion: the earlier the user find an error in the XML file the 
better is it. With the XML schema
you have more possibilities than with a DTD because it is a superset of 
a DTD.
Beside obvious advantages (like XML schema uses the XML syntax) as a 
concrete example we can
use some build in data types like QName, ID, IDREF directly with the 
schema. Or for the JCR
date types we can use the double, date, long, boolean schema types.
A binding framework can do the conversions. Which means, once we defined 
a double or any other
datatype in the schema we don't need to deal with parsing, validation or 
conversion from string
to the according data type. The type will simply be available in the 
Java bean.
I think a XML schema is not much more complex than a DTD when they cover 
the same
requirements. I'm not sure if it is representative but please have a 
look at this page for
a simple example:

The argument which is maybe most important for me:
In my opinion it is more than a config file. I think it is some kind of 
model (like the one in MVC)
for the mapping between Java entities and JCR entities. Therefore I 
would like to have an
in memory Java bean representation of that model. This mapping model can 
than be the basis for
every conversion between the Java entities and the JCR entities e.g. it 
can be used for:
o writing Java objects as nodes to the repository
o loading nodes from the repository into Java objects
o generating node types out of Java classes
o generating Java classes out of node types
o ...

A simple change in the XML schema file would change the model (the 
generated Java beans)
after regeneration and this changed model would be immediately available 
for all components
using this model.

 >* See
I checked the described drawbacks there. Here are my comments:
"you need an xml schema that defines your input xml"
As I already pointed out, I see this as a good thing.

"you need to run a "pre-processor" to generate code"
I afraid I don't get the point here as I think you would need to write 
the code by yourself
in the other case.

"you may or may not have much choice about the names of the generated 
classes, or the
way inter-object relationships are represented."
I would like to control the names and the structure with the XML schema.

"the generated classes don't contain any "business logic", just plain 
getter and setter methods
for the data"
I my case it's a model which must not have any business logic.

"if you modify any of the generated classes, then later need to 
regenerate them because the
schema has changed, your changes are wiped out."
It should be a simple model filled by a XML file and like I said before, 
I worried about
the extensability of JAXB 1.0. But the XMLBeans feature list says:
"Extensions - You can now add custom functionality to generated 
XMLBeans. You can
pass to the Schema Compiler 1) an interface that defines the set of 
methods to implement
and 2) a static handler that implements this functionality. The 
generated classes will
implement the and, for each method, call out to the static handler."
At the moment I would say we don't need injected functionality, but who 
knows... ;-).

Kind regards,


View raw message