Scaffolding a Generic Admin - Part 3 - Illudium Code Generator Template

If you are not using Illudium to generate your application classes, I encourage you to check it out. Out of the box, the code generator comes with several templates for generating CFCs, Transfer and ColdSpring XML, Actionscript VOs (value objects) and TOs (simple transfer objects designed for Flex development). Modifying, or creating your own templates is encouraged and easy. The template I developed for this series uses ColdFusion templating, but you can also use XSLT or a combination of both...

Illudium connects to the ColdFusion administrator, so you will need to enter your CF administrator password when you launch or reload Illudium. When you pass the authentication stage, Illudium prepares a list of datasource names that you can choose to select the tables that will form the basis for your generated code.

For this post I created a MySQL database named "triviagame" and ran the MySQL script from Part 2 to create the tables. After creating the database and tables, I also created a datasource name called "triviagame".

To view and/or save the generated code you will need to unpack the enclosed archive into the folder /xsl/projects/ found under the Illudium web root folder. After extracting the files, you will be able to choose the the "transfer-dispatcher-cfm" template from the list of available templates.

If you quickly compare the files generated from this template with the default template, you'll notice that it is purposefully lean. Transfer ORM makes this possible. I'm using Transfer for all CRUD operations (in place of a DAO) and list queries (in place of a "Table Data" Gateway). This allows me to focus on the controller, service and decorator CFCs. Let's take a look at some example code generated from the "trivia_game" table.

Below is the generated code for GameService.cfc.

For methods that return a Game, you'll notice that I invoke a couple of methods, setTransferMetaData() and setParents(), prior to returning the object. These methods are designed to make the TransferObject more "self-describing" in support of the generic "Form", "Bean" and "List" views that make up the generic admin. We'll revisit these later in the series.

The other portion of code to note it the "setXXX" methods invoked in saveGame(). Here lies the justification for my PK/FK naming convention. A TransferObject must be fully composed prior to being saved. In this case, a Game has a parent User and Theme, but the arguments for saveGame() are simple form variables (UserId and ThemeId) passed to it from the Game controller. I've set up the template to check for any attribute containing "Id" in the name, so that the proper compostion method can be called. For example, we need to use

instead of

Did I mention that I'm happy Brian added CFM templating to Illudium? Pulling that type of manipulation off in XSL would have been a big headache for me!

Next we'll look at the generated code for GameController.cfc.

The controller CFCs generated from this template extend "com.fancybread.event.RequestListener" which is part of the Dispatcher event pacakge. A RequestListener has an onRequest() method which receives a generic event object. I will explain the inner workings of a Dispatcher application in more detail in my next post. For now, all we need to know is that there is a controller for each business object and that the onRequest() method is invoked on all controllers for each page request. Whether the controller takes action based on the event is decided by the logic within onRequest().

Next we have the TransferObject Decorator.

Being able to decorate a TransferObject gives you the flexibility harness the power of Transfer while adding methods that you might like to use for business objects. In addition to the methods that enhance the "self-describing" nature of a TransferObject, I have added methods that add support for validation (isValidForSave(), addError() and getErrors()) and a generic getProperty() method.

The two other parts of the template create code snippets to be cut and pasted into transfer.xml object definitions

and ColdSpring bean definitions xml.

There's a fair bit to digest here and it may not make a lot of sense at present. It's my hope to provide some clarity to the picture when I continue with the following post(s) on how to set up a Dispatcher application.