From graffito-dev-return-398-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Thu Aug 04 22:00:15 2005 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 6382 invoked from network); 4 Aug 2005 22:00:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Aug 2005 22:00:14 -0000 Received: (qmail 5378 invoked by uid 500); 4 Aug 2005 22:00:14 -0000 Mailing-List: contact graffito-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: graffito-dev@incubator.apache.org Delivered-To: mailing list graffito-dev@incubator.apache.org Received: (qmail 5365 invoked by uid 99); 4 Aug 2005 22:00:14 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Aug 2005 15:00:14 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of sandro.boehme@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 04 Aug 2005 15:00:05 -0700 Received: (qmail invoked by alias); 04 Aug 2005 22:00:12 -0000 Received: from p54A3F26E.dip.t-dialin.net (EHLO [192.168.2.2]) [84.163.242.110] by mail.gmx.net (mp030) with SMTP; 05 Aug 2005 00:00:12 +0200 X-Authenticated: #1646957 Message-ID: <42F290A9.5060806@gmx.de> Date: Fri, 05 Aug 2005 00:03:21 +0200 From: =?ISO-8859-1?Q?Sandro_B=F6hme?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: graffito-dev@incubator.apache.org Subject: Re: [jcr-mapping] persistence of the mapping model References: <42E959B2.5030302@gmx.de> <3b728ee9050731134776c1cb62@mail.gmail.com> <42ED4ABD.8090109@gmx.de> <42EFAC51.2020104@gmx.de> <3b728ee90508021119215fd88a@mail.gmail.com> <42EFE7B6.6090801@gmx.de> <3b728ee9050803015769e479b8@mail.gmail.com> In-Reply-To: <3b728ee9050803015769e479b8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N >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