Proposal 1 (Christophe)
----------------------------------
* I'm doing a prototype - see in the head (subproject jcr-mapping).
The starting point is the unit test called : JcrSessionTest
This code do the following steps : * Read the mapping file with
Digester and load it in memory (object
graph) - See the class DescriptorReader in the prototype. The
prototype is not complete.
* A simple DTD is sufficiant for this kind of operation. * Use
BeanUtil to convert in both direction pojo <-> jcr node (see in
the prototype the class : GenericConverter).
+ : simple code and light tools
- : classes used to read the mapping file have to be write by hand.
Thanks to the limited number of classes, it should not be a problem.
Proposal 2 (Sandro) ----------------------------
* Sandro made a prototype - see in Jira ( GRFT-34) :
http://issues.apache.org/jira/browse/GRFT-34
* Use XmlSchema and tools like JAXB or XmlSchema to manage the xml
mapping file.
Arguments for XML schema and XMLBeans:
+ : The XML schema and the mapping class model are redundant
information in my opinion. So for me
it seems to be straightforward to generate the mapping model classes
out of the XML
schema (e.g. with XMLBeans). You will need to change the mapping class
model if the
specification of the XML file changes and vice versa.
+ : Isn't it also possible for Digester to use XML Schema? I think so,
but I guess I'm not the
Digester expert here.
+ : The XML schema and the classes should not get out of sync.
+ : With the type support of XML schema I think we could reproduce
many of the JCR
entities from items down to concrete JCR property types and of course
Java bean
structures. This makes it possible to have very much semantics of the
XML file already
validated by the XML schema.
- : A Class and an Interface is generated for each type.
- : As XML Beans is a generator is should be sufficient to have the
license in the xsd file.
But to be sure I would like to have it in the generated classes. This
would need some
extra effort. Of course I'm in charge to care about it.
- : Extensions to the generated classes should not be needed very
often. In case it is
needed, the classes are extended in a not quite familiar way.
Why I'm not agree with Sandro :
---------------------------------------------- I don't see the
advantage to use the XML schema in THIS case. The xml
mapping file has to be quite simple to read and generate classes is
overkill in this situation. We can do exactly the same think with very
light tools... but maybe I'm wrong !
Hello Christophe,
if you are back from vacation and read my arguments and you are +1 for
Digester anyway, I'm
+0 for Digester for not slowing down the project. Basically because it
is only a matter of work
to keep the XML file specification in sync with the mapping class model
and it will not have
any impact to the user.
But at the moment I don't see any arguments contra XML schema.
Regards,
Sandro
