Hi Patrick, Patrick Moore wrote: > > Hi Keith --- > > Is this information going to be able to be read from the schema file? If the > answer is no then I will work on a patch that lets the information to be in > the schema file. The current answer is no. Many Schema files come from 3rd parties. We feel that any binding information should be kept separate from the Schema itself. A copy of the Schema could always be made and the user could add the binding information, but this leads to additional maintenance of the Schema files, especially if they are changed to add additional elements and attributes. This would mean you would have to re-edit your schema changes. We really feel a separate file is best for the general solution. > The reason is that I would like to have all the information > in the schema file so that the data definition is self contained. If I > decide to move to a different source generator this would enable a > conversion to that new source generator's appinfo format using XSLT. Assumming that a new source generator uses the appInfo. But using XSLT you could also move the information from a separate binding file into the Schema itself if you ever needed to... > If I have a series of .properties files I get no such flexiblity. The .properties files were simply a "current" work-around to the problem. Enabling the problem to be solved today, without waiting for the binding file support to be committed to the CVS. The binding file is not a .properties file, but an XML file. Arnaud could give you more information about it's specific structure. Perhaps he could add the Schema for the binding file to the enhacement request in Bugzilla. > > If I came up with such a patch would it be rejected out of hand? > You can always make your patch available to users on this list, and if it gains wide acceptance by the user community we could commit to the CVS...however it does go in a different direction than the one we are already planning. We try to let the user community shape Castor's direction however, so if your patch gains wide acceptance, perhaps we can use a combintation of both approachs. XSLT can also be used to extract your specific AppInfo and create a Castor binding file. Thanks, --Keith > >-----Original Message----- > >From: Keith Visco [mailto:[EMAIL PROTECTED]] > >Sent: Monday, February 18, 2002 2:37 PM > >To: [EMAIL PROTECTED] > >Subject: Re: [castor-dev] defining superclass, and interfaces in xml > >schema file. > > > > > > > >Hi Patrick, > > > >Please see: http://bugzilla.exolab.org/show_bug.cgi?id=882 > > > >Arnaud has been working on the binding file for Castor which will give > >you the features you need...such as specifying class names, specifying > >interfaces and a superclass, etc. > > > >A single super class can already be specified using > >castorbuilder.properties. This super class can contain the "implements > >interface(s)" that you need. However this superclass is used for all > >generated classes (except descriptors). > > > >A work around to allow finer grained control is to split your schema > >into multiple schema for the purpose of source generation and use > >multiple castorbuilder.properties files for specifying different super > >classes. This is only for the purpose of source generation and > >your main > >schema would remain in-tact. It's just a work-around until the binding > >file has been commited into the CVS. > > > >Thanks, > > > >--Keith > > > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
