hibernate-devel

[Hibernate-devel] code generator

[Brad C. <bra...@wo...>]

i have built a small code generator based on the hibernate mapping file.
it enables us to automatically generate the classes specified in the
mapping file (no hand writing all those getters and setters :-)).  i
have tried to make it extendable and configurable so that other classes
(eg. data access or business logic) or web pages, etc could also be
automatically generated.

so far, it has been a tool that has been built and added to as we have
needed, and therefore doesn't support all the mapping features
available.  for example it doesn't do:
	toplevel collections
	components
	primitive types

but it does do:
	nested collections
	one-to-many
	many-to-one

there is also no concept of regenerating changed existing classes and
automatically merging the changes.  finally, as this has not been a big
focus for us, the code/docs r not always very pretty.

in light of all that, i use it regulary and find it saves me time.  our
company (workingmouse.com) has decided that should there be any
interest, we can contribute it to the hibernate project.

in light of the recent discussions on automatic generation from a
database, i can't c y the code generator could not be extended to use
the mapping file, or an existing database.  currently, the code
generator processes the mapping file into it's own internal structure
(it can't use the existing hibernate code that does this as it relies on
reflection and the classes don't exist yet).  this initial processing
component could be made configurable and one that generates the internal
structure from an existing database be written.

brad

> _______________________________
> brad clow
> chief technical officer
> workingmouse
>=20
> email: bra...@wo...
> web:   http://www.workingmouse.com
>=20

[Hibernate-devel] code generator

[Brad C. <bra...@wo...>]

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=3D" 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
>=20
> email: bra...@wo...
> web:   http://www.workingmouse.com
>=20

[Hibernate-devel] XSLT code generator

[Anton v. S. <an...@ap...>]

Since I said I would, I've put up a copy of my nascent XSLT code generator
at
http://www.appsolutions.com/hibernate/BeanGenerator/

There's a ZIP file which you can download if you want to play with it, and
links to the source files if you just want to look at them.  There's a
readme.txt included with a bit of info about its use, features, and current
limitations.

It's very small and simple: a 47-line XSLT file, and a supporting Java class
that's about 80 lines, excluding comments.  The XSLT does a fair amount of
magic in terms of understanding and handling the Hibernate mapping file
format, and this keeps the overall code size down.

It's not my intent with this to "compete" with Brad Clow's generator, but
some cross-fertilization of ideas is never bad, IMO.

In fact, I'm very much in favor of the kind of high-level approach Brad
described:

> 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.

I have another set of Java classes to reverse engineer a database and
generate a Hibernate mapping file.  The overall architecture of that is
somewhat similar to Brad's generator, since I wrote it with a view to making
it part of a more general metadata manipulation suite of the sort we've been
discussing.  I think this could be integrated with Brad's generator without
much problem, so I may post more on that subject over the next few weeks.

Anton

P.S. Any feedback on my use or abuse of XSLT is welcome - I last used it
seriously in 1999...