i have just commited the first (very rough) cut of workingmouse's code generator to cvs. over the next few days i will try to make time for writing javadoc comments. there is an ant task (codegen) that runs the code generator over a test mapping file (cirrus/hibernate/tools/codegen/test/hbmapping.xml) and places the generated files under a "generated" directory.
mapping file requirements: all properties and id's in a mapping file must have the type attribute specified. currently a type must be a fully qualified java class, with the one exception being the hibernate binary type. supported mapping file functionality: subclasses nested collections one-to-many many-to-one high-level architecture: our goal is to use the code generator to generate the javabean classes defined in the mapping file, as well as many of the other classes, web pages, etc. that use them. before writing this i weighed up the idea of using XSLT. firstly, i haven't written any XSL, XPATH, X..., for about a year now, so i am a bit rusty with it all. secondly, i didn't think it would elegantly achieve our goal compared to just using java and/or a template mechanism like velocity. ok, so at its core, how does it work? essentially, the mapping file is parsed into an internal structure and then a renderer used to write the internal structure into a series of files. i have included one renderer (the BasicRenderer class) that simply writes out the classes specified in the mapping file. anybody can write more renderers by implementing the Renderer interface and configuring the code generator to use their renderer(s). gavin i did have a renderer lying around here somewhere that used velocity, which although not as powerful was very easy to use. i would like to resurrect it and commit it as well. however this will introduce a dependancy to velocity (http://jakarta.apache.org/velocity/). is that a problem? configuration: the code generator can be used without any configuration, but the location of the mapping file to process. this is how the ant codegen task is setup. in this scenario, the BasicRenderer is used to write the classes defined in the mapping file under a directory called "generated". however, a configuration xml file can be used by specifying its location with the "--config=" command line parameter. (there is a test config file located in cirrus/hibernate/tools/codegen/test) the config file enables u to specify generators. a generator is simply a renderer plus information about the base directory to write the generated files to, package to put them in and how to name them. database reverse engineering: currently the code generator revolves around the mapping file, because that is the way we like to work. however, i can't c any reason y the parser code couldn't be abstracted away behind some sort of Parser interface and made configurable. this could enable a "database parser" that uses the JDBC meta data of an existing database to build the internal class structure. the problem would be in writing the single mapping file, as the architecture isn't really geared for that. i am sure we could come up with something though. hope this is useful for people. brad > _______________________________ > brad clow > chief technical officer > workingmouse > > email: [EMAIL PROTECTED] > web: http://www.workingmouse.com > _______________________________________________ Hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
