Hi Wei,
> > > I'm quite new to castor and my knowledge of castor is > > > limited. I have been > > > wandering if the current castor provides a "more" automatic way of > > > generating the source code in the following situation: > > > > > > (a) > > > - DTD schema are defined. > > > - Use SourceGenerator to generate classes and class descriptors > > > > No, you have to convert your DTD to XML schema (The furture > > is anyway xsd instead of dtd). > > > Sorry, a typo. I did mean xsd. Sorry, but I don't see what you mean, by having XSD files (XML Schema) you can generate your Java code, what should be more automated on it? > > > (b) > > > - Have my own classes that are inherited from the generated ones. > > > > Yes, configure the castorbuilder.properties file with your own > > supar class. > > A example > > of that file can be found in the source distribution. Look > > in the package > > 'org.exolab.castor.builder'. To make use of your edited > > version of this > > properties, include > > it in your classpath, before the castor package! > > Although there will be a common base class in my > application, each class > that supports an XML type needs to extend from the generated > class in order > to accomplish the task required by the application. > > If I understand correctly, the properties mechanism provides > inheritance > support for all the generated classes, it does not support individual > mappings at run time. For example, generatedA.java to extendedA.java, > generatedB.java to extendedB.java. For as far as I know, the Source Generator can only inherit from one super class, but you can of course have multiple XSD files, which all could have their own castorbuilder.properties file, in which each time a differned super class is specified. > > You are asking a lot of technical questions, but could you > > explain what you realy try to solve / do. > > For me it's not clear what your read problem (/ project) > > is. I get the feeling that > > you try to solve something which maybe could be solved > > easier. But for now it is > > difficult to gain a comprehensive view of the real problem. > > The problem I'm trying to solve is that while the generated > classes give > marshaling/unmarshalling algorithm which I'm really interested in, the > generated implementation of getter and setter methods needs > to be modified. > The application uses RMI to communicate between the client > and server, and > the server also needs to communicate with its own > "server/device" to do the > real getting and setting job. As such, the server needs to > do a bit more > for the getter and setter methods for different "kinds" of > XML elements, > even though the xml elements can be classified into only > small number of > different "kind" of classes. > > I'm sure some applications out there have the similar problem > using the XML > binding mechanism, it will be interesting to hear other > people's approach. Did you think of the DAO pattern? Maybe this could solve your problem. The DAO is responceable for getting and setting the the valuebeans values from the 'backend' application (database, mom, or other service (server/device)). See the Sun site for details: http://developer.java.sun.com/developer/restricted/patterns/DataAccessObject .html Tjeerd references: J2EE Patterns: http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/ Class diagram: Business Logica and Data Access layer The Business logic layer makes use of value beans, which can be retrieved and stored through a Data Access Object (DAO) layer. The concrete implementaion of that layer can also be easily changed in this way. The class BLXxxx makes use of the interface DAOXxxx. The get a concrete implementation of a DAO, the DAOFactory is used DAOFactory.getDaoXxxx(). These BL's can also contain calculations / validations between differned value beans and they can call eachother off course. Then every application Swing / Web (Servelts/JSP/Struts) can use the BL layer. In this example two differned methods to connect to a database are used, but they can easily be converted to MOM or other services. +--------+ +--------+ \ | BLXxxx | | BLYyyy | > Business Logic layer +--------+ +--------+ / | | | | | | | | | | | | | V V | | +--------------+ | \ +--------------------------+ | | DAOFactory | | | | The DAOFactory uses a |\ | +--------------+ | | | doa.properties file in | \ | | | | | | which is specified which +--+ V | | V | | concrete instance should be | +- -- -- --+ | | +- -- -- --+ | | returned by the DAOFactory. | | DAOXxxx | | | | DAOYyyy | | +-----------------------------+ +- -- -- --+ | | +- -- -- --+ | ^ ^ | | \ | | | +--------+ \ : | \ | +- -- -- -- --+ | > DAO Layer : | / | V | V / +----------------+ +----------------+ | +----------------------------+ | JDBCDAOXxxx | | CJDODAOXxxx | | | The DAO implementaions use |\ +----------------+ +----------------+ | | ValueBeans (Xxxx) that are | \ |+ insert(Xxx) | |+ insert(Xxx) | | | returned to theBL instance.+--+ |+ update(Xxx) | |+ update(Xxx) | | | Or gotten from the BL layer, | |+ delete(id) | |+ delete(id) | | | and 'stored' in the DB (for | |+ getAll() | |+ getAll() | | | example). | |+ searchById(id)| |+ searchById(id)| | +-------------------------------+ +----------------+ +----------------+ | } } / | | | | | | V V +----------+ \ | Xxxx | > Value beans layer (Generated from XML Schema) +----------+ / +-- -- -- --+ | interface | +-- -- -- --+ +-------+ | class | +-------+ <-- -- These 'arrows' represent implements interface. <------ These 'arrows' represent uses. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
