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.