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
content.
* See http://wiki.apache.org/jakarta-commons/Digester/WhyUseDigester.
Give 2 days, I hope to commit a small example (before my upcoming vacations).
Christophe
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:
http://www.w3schools.com/schema/schema_howto.asp
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 http://wiki.apache.org/jakarta-commons/Digester/WhyUseDigester.
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,
Sandro
