Programming with
a dose of satire.
Programming
|
| ||||||||
 |
 |
|||||||
|
Programming |
||||
|
Generate Enterprise Applications With JGenerator
Automated code generation has found its way into the mainstream programmer consciousness. In most enterprise projects these days, using a code generator can be a life-saver - though many teams are still unaware of the benefits that code generation offers. This tutorial provides a practical, working example showing how a code generator can be used to generate a web application with a database back-end. For the purposes of this example, we're limiting ourselves to three database tables - hopefully this should be just enough to give you some of the flavour of what code generators can achieve. Before we get started, you might find it useful to have a quick read through this article (introduces basic code generator concepts and principles). The generator we're using for this example is JGenerator, by Javelin Software. This is a commercial product, but there's also a free version available for download, if you want to try out the example for yourself. The free version provides all the features of the full version, except it's limited to 5 database tables.
What is JGenerator? JGenerator is a model driven code generator. It's "model driven" because the problem space is described in a business description language (BDL), and out comes code, be it source code, HTML, JSP, whatever. It’s as generic as that. JGenerator comes with many code generation modules (called ‘writers’) and the ability to configure them as you will, as well as adding your own. The fact that all the source is available means that there are no black boxes, no jumped up wizards to deal with, you never have to fight with the generator to get it to cooperate, as you are always in charge. Basically ‘readers’ pull in meta data, be it from the BDL or an existing database, to create an in memory dictionary, which is then output by various writers.
This tutorial shows you how to get started with JGenerator in order to build your first domain specific API and framework. For further reading, perhaps in parallel to this article, go to www.javelinsoft.com/jgenerator or www.javelinsoft.com/jgenerator/guide/
Our Example Web-Based Message Forum In this article we’ll build a simple message forum modelled loosely on the www.SoftwareReality.com forums. The basic premise behind the SR forums is that each article can have a simple guestbook-style forum attached to the end. Simplicity is key - this isn't a "community" website like JavaLobby, TheServerSide or Slashdot; but it's also useful for people to be able to post feedback to individual articles. This example is kept simple to aid understanding, although in reality most systems that need a code generator would have at least 6 tables. Here's the ER diagram for our "dog-simple" message forum example:
Getting Started Assuming you’ve got JGen installed, the first thing to do is create a directory for this project, say c:\forum. Under that we’ll create a directory called 'web', which is the root for this project when mounted by the web container. Under web, we’ll create:
which is a good place for our classes to live. Then we’ll create a package for this project. For this project we’ll be using com.softwarereality.forum Then we create a BDL (Business Definition Language) file for the project in c:\forum\web-inf\classes and set the package and the root directory of the package hierarchy, as well as the context name (name of the project as a whole) so that the writers know where to output things. We’ll call the BDL file forum.properties. There's a link to the finished BDL/forum.properties file at the end of this article. In the course of the article, though, we'll go through the process of creating the BDL file step by step. Here's the first part:
The dollar signs are for macros we create that can be used elsewhere. For example, we've defined a macro called $ROOT, with the value c:/forum/web. Now wherever we put $ROOT, it'll be replaced with c:/forum/web at generation time.
The defaultdbl File The BDL files aren’t very big, as when we parse them we first pull in a global defaultdbl.properties file which defines most of the useful defaults for a project. For example in the defaultdbl we have $GENERATOR set up to point to the generator root package, as used below:
Setting up the Readers and Writers As you might expect, the readers read in meta-data (e.g. BDL files), and the writers write these out in various formats (Java files, XML, SQL, JSP and so on). JGenerator's modular nature means that readers and writers can be used interchangeably. Want to generate EJBs instead of 2-tier beans? Just swap in a different set of writers. This is achieved via an intermediate data dictionary which JGenerator holds in memory whilst generating. Anyway, here's how we define which readers and writers we want in our forum.properties BDL file:
The PropertiesReader simply reads properties from the BDL to create the dictionary. The 'AggregateWriter beans' line calls the following group of writers in the defaultdbl:
You can create your own groups of writers easily, just say:
Then call
SortedPropertiesWriter (which is declared in the above snippet from forum.properties) is simply a little debug writer that emits the parsed properties in alphabetical order. It isn't needed for runtime, but it's nice to see what is actually acted upon, as complex macro substitution and defaultdbl inheritance can get a little confusing. In fact, it’s a tiny little writer, and even though this tutorial doesn’t focus on how to create your own writers, here’s an example of how small, yet useful they can be:
JDBC Writer - Persistence The AggregateWriter called 'jdbc' does as you expect, calls the JDBC group of writers:
Because of this process, if you suddenly decided that you needed another class emitted when processing JDBC then you could easily say:
in your forum.properties, and the jdbc group would now be altered to include this new member. We also need to define the database vendor, so that the generated SQL code is correct:
We could similarly tell the generator to output to oracle|ms|Sybase|db2|interbase, for example: forum.vendor=oracle Next we need to tell the JDBC layer where to pick up the database info:
This tells the generator to look for the file jdbc.properties. This file would contain something like:
Notice that each line starts with "forum". This is because we define a database via a source (in this case "forum"), which is detailed in the jdbc.properties file. This allows us to easily switch database details without always having to recompile.
Running The Generator Now we're ready to run JGenerator on the BDL file that we've created so far. There are several ways that JGenerator can be run, but the easiest way is simply to create a class like the following, and run that from within your IDE:
JGenerator also has its own GUI for generating code and analyzing the results. To run this, run the com.javelin.generator.JGeneratorIDE class. Follow the on-screen prompts after that - it's pretty straightforward.
When JGenerator is invoked using our example BDL file, it cranks out classes in the com.softwarereality.forum package. In the same process, JGen creates the SQL in the sql directory C:/forum/web/WEB-INF/classes/sql Like most things this can be changed by defining an sql.pathName property. As we have none, JGen uses the default.pathName, defined above. The SQL files are used to create a suitable database, delete all data, drop all tables, etc. e.g for SQL Server, the following SQL is generated:
As for the Java classes we get bean interfaces, implementation classes, JDBC sessions/homes, lazy (caching) classes, etc. All the generated forum code is automatically Javadoc'd. You might also be interested in the Javadoc for our FPML project (a huge project with loads of generated classes).
Generating JSP Next, we'll show how to add some writers for creating JSP and JSight files. The JSP writers emit JSP fragments for UI use. These are particularly easy to drag/drop into DreamWeaver, because the writers create DreamWeaver library elements. JSight is an automated Admin web application that comes with JGenerator. It allows you to create, edit, delete, sort and query data. Here's an example for Northwind.
And in forum.properties:
For example to show the http://www.softwarereality.com/forums.jsp page:
Lots more info in the JGenerator guide. An important point about JGenerator is that it doesn't have to emit just Java. That's its current focus; however, there is nothing to stop users from creating their own writers, but using the same readers and dictionary. JGenerator also has a set of writers for generating EJBs. However, EJB sucks, so we tend to avoid wherever possible. With JGen it's easy to create your own engines instead of relying on other peoples' black boxes. However if you want to do EJB, go ahead. Finally, here's the finished BDL for our dog-simple forum example.
Conclusion With this tutorial, I've aimed to provide some insight into how useful code generators can be - and how they can generate reams of source code (and supporting files, e.g. Javadoc) with very little effort. This was primarily a tutorial about using JGenerator, so as you'd expect, I talked mostly about JGenerator. Matt's article gives some links to other code generators, but my feeling (having written part of JGenerator myself) is that JGen provides a number of advantages. In particular, we give you all the source code (even the free version includes some source to play around with). We've also encapsulated many years of consultancy experience in the code that the product generates, i.e. it doesn't generate inefficient or "beginner" code. We also use JGenerator on our own consultancy projects at Javelinsoft, so it wasn't created inside an ivory tower to an idealistic design (unlike the EJB spec, for example). While I'm at it, we don't default to generating EJBs just because that's what everybody else is doing (ride that bandwagon!) Instead, we generate whatever is most appropriate for getting the job done.
About the author: |
||||
By 
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.