This weeks' model

Since chatting with Peter Bell at 360 Flex, I’ve been doing a lot of thinking about the base model for my Flex-and-ColdFusion Intranet application, “Stream”.

This application was pseudo reverse engineered from a Visual Basic application and has nearly 200 tables of inter-related data – mostly without primary or foreign keys, but that’s another story entirely. For a long while there has been no clear and overall model of the application. The tables and views were mostly responsible for driving the application but there is still a lot of business logic tied up in various peoples’ heads. This is obviously not an ideal situation, as it dramatically raises the bar of entry on this project for any other developers.

As a direct result of the planned migration from Flex 1.5, to new-and-improved Flex 2.0.1 (including the usage of Flex Data Services), I now have to rework the ColdFusion tier. This seems like a good time to rethink how the application works, apply some consistency to the application as well as build up a global model to develop from. Hopefully there will also be a page or two of documentation. 🙂

When working on “Version 1” of Stream I spearheaded the generation of a lot of the code on for the ColdFusion and Flex tiers, which included various parts of code for usage with Cairngorm in Flex as well as unit tests for ColdFusion. However this code was fairly brittle and an increasing number of complicated edge cases meant that eventually the generation was one-time only. The result of this was that this was barely better than no generation at all.

So for the last few weeks, I’ve been playing around with ideas for the new model and how to generate code for the three effective tiers – ActionScript, ColdFusion and database (accessed via an ORM). This is resulting in an bespoke generator application that I’ve named Dynamo. But code generation is only a part of the purpose of Dynamo. The source for my model is the database, so obviously I’ll need to validate my model against this – checking usage of fields and automatically using the database as the basis for any typing information; and as the end result of the application is to display these fields in a Flex UI, I need to validate that I am using all the fields required for each part of the model. This combination of techniques should allow rapid development based on our existing data while dramatically minimise the number of errors caused by missing fields, typos or incorrect data types.

For the generation part of Dynamo, after much thought and reviewing of options I’ve fallen back on an old favourite technique – using XML for the model and XSLT for the generated files. Based on ideas from Peter, I was originally intended to put all of this model meta data into the database itself. However after some initial attempts at putting a hierarchical data model into a database, I realised that I was overly complicating things and that the “simplest thing that could possibly work” was to work with an XML file for the time being – if required later I can always rework my model code to use a database. One drawback with using XSLT is that many people find it complicated and difficult to work with; at some point I’ll replace this with a simpler templating method.

However, one big advantage of using XML and XSLT is that I can incorporate this into my ant build script so that all of the generated code is created when “Stream 2” is compiled and deployed, and the generated files are not checked into source control. This keeps the focus of change entirely on the model and the templates, not on the generated files themselves.

Ideally I’d have a dynamic and active generator – change my model, next request all the changes are reflected. The problem is that I need my VOs for ActionScript to be generated to be compiled into my application, and ColdFusion requires physical files to automatically translate classes to ActionScript. As an aside, I was talking with one of my friends who works in the finance industry and when I told him I was using XML and XSLT he embraced my like a brother exalting the virtues of XLST programming. But when I told him I was generating my code, he became disgusted and seemed to want to pray for my eternal programming soul 🙂

These are still early days, but I’ve switched back from focusing on Dynamo to Stream -which of course was the whole point of this whole exercise. I’ve now started wiring up a number of screens, and apart from the occasional typo or missing field (which is why I need to validate), the development is proceeding rather quickly.

[Addendum: a few weeks later]

The base idea behind this modelling has worked really well – I was able to wire up a lot of screens with data, in rapid succession, with only a small amount of code required – the rest was generated. I’d like to componentise more on the Flex side, but so far the ColdFusion side is working well. However, I’m yet to need to customise the ColdFusion code – and this is where generated code tends to fall over. Dynamo at the moment is sliding away from being a separate application, and may end up being tied into the main code-base of Stream. One unfortunate and unforeseen side effect of this generation system is that I now need to generate my code for the application to work – otherwise there is no base ColdFusion components to handle data accesses. This means that my build times in CFEclipse are in the realm of 20 seconds – hardly ideal.

One response on “This weeks' model

  1. Peter Bell

    Hi Robin, Sounds like you’re having some fun there and doing some cool stuff. Depending upon runtime performance requirements, remember that you can implement model interpretation as well as or instead of model compilation if you want to cut down on the compile cycle (you could even create an approach like the one I use internally where you have the option of either generating or interpreting your models and can change depending on whether you want to test or deploy to production). Think base classes and you’ll probably figure it out, but if you want, I’ll give you a peek under the hood of how we’re doing this stuff at Scotch just in case any of the ideas will be of use down the line.

    Always good to see more people playing with code gen. If you can, mark the Code Generation conference in June next year in your calendar – I think you’d really enjoy some of the ideas there!

    See ya at Scotch!

Leave a Reply

Your email address will not be published. Required fields are marked *