« AC2k7 - Flex2 and beyond, LiveCycle 8, Apollo, Cairngorm 3, Methodology and Madness, Design Led Innovation and more ! | Main | On Labs: The Artist formerly known as Flex Data Services »
January 08, 2007
Cairngorm Code Generation
I'm increasingly questioned about how much code-generation we employ when we're developing our own solutions upon Cairngorm; let me address this point with a look to the past, the present, and the future.
The Past - From UML to Code Generation for the Mother of Cairngorm
Way back in the past (1999-2000 timeframe) I was a huge advocate of UML and roundtrip engineering; in fact some of my now Adobe Consulting colleagues were colleagues in a past-life, where we were ardent users of the Together UML tool for Java. Together were acquired by Borland, and Together UML now ships with Borland IDEs I believe.
Around the same time I began to sip from the agile firehose, I became less interested in UML modelling and model-driven development techniques. It was around this same time that I first was exposed to the Core J2EE Design Patterns from the Java One presentations by Alur, Crupi and Malks, and developed my first architectural framework using these patterns in Java. We called the framework "Mesh" (as in a wireframe mesh for the application, remember this was before struts, but same idea) and found ourselves laboriously writing lots and lots of repetitive "handle-turning" code. Mesh was the mother of Cairngorm I guess, in that Cairngorm took a subset of the design patterns that we leveraged in the Java world. In Cairngorm, we discarded the Data Access Object (DAO) pattern, the Business Delegate became a much simpler facade onto server-calls, as opposed to an almost object-to-relational bridge between the Java value-object world and the JDBC PreparedStatement and ResultSet world for Create, Read, Update and Delete methods. And of course, the value objects mapped very closely to the underlying database structure, as the DAO pattern adapted tables to objects.
We found that any story (feature/use-case) we picked up for development would inevitably be a bottom-up development of "add/augment a database table, update the value object definition, create a new DAO if it was a new table or view on the database, or tediously update lots of SQL queries and iteration over ResultSets if we were simply adding columns to a table, write new methods on the DAO, and then write new methods on the appropriate Business Delegate class to call the new DAO methods, adapting ResultSets into value objects and value object graphs. Only then would the story-specific fun begin, as we implemented Command classes and JSP to render the view. Boring, boring, boring.
With all this tedium, I turned to code generation of the value objects by JDBC introspection of the database metadata (creating value objects per table, and attributes on value objects according to columns in the table). I'd then code generate the DAO classes, all the CRUD operations and queries, and the business delegate methods for each DAO method. It was all very crude (perl initially, Java eventually) code generation, and inevitably we'd step in and do some hand-coding or optimisations to the code anyway, which meant we then didn't want to rerun the codegen (it wasn't as clever as being round-trip code generation).
I'd argue that with all this tedious VO, DAO and Business Delegates upon a database tier, the effort for code-generation just about paid off for us.
If you're interested in this kind of approach, from database through Java-tier all the way to creating client-side code (not Cairngorm based) and a view, the team at Farata Systems have created DAOFlex that will do exactly this kind of code generation, much more elegantly than my home-brew approach at the time as well There's an article on Adobe devnet that will get you started.
The Present - Adobe Consulting on Cairngorm Code Generation
Right now, I'd say that the amount of code that we would typically usefully generate hasn't really justified the effort; code-generation is a decision that a technical architect will make on a project by project basis, but it certainly isn't in our arsenal of practice-wide techniques that we apply to each and every project.
Peter Martin did make some attempts with the XDoclet 2 work that he did, building on some work by Joe Berkowitz of Allurent. As you can see from his blog entry, it was a lot of work to create value objects only, which in the grand scheme of our typical projects, don't account for a whole host of development effort and time to maintain.
So in summary; right now we're not employing a great-deal of code generation and don't feel that we're suffering in productivity because of it. Those coming from a Ruby on Rails background are often impressed at the ability to automagically generate so much scaffolding for CRUD type applications - I think the DAOFlex approach may work for you here, and remember we're never necessarily advocating Cairngorm for your simpler Flex applications anyway. Someone asked me in blog comments recently whether Cairngorm and Flex could be more complex than Ruby on Rails with AJAX, and I guess sometimes it can be. However, those are two poles of a spectrum, and in-between there are a number of much-simpler non-Cairngorm Flex approaches that can be taken to rapidly deliver simple applications. There are times when i think you shouldn't use Cairngorm.
I guess under the present tense, I would like tomention the work that has been done by Eric Feminella in a project he has called Cairngen. Eric's motivation is to remove the repetition associated with creating Events to be registered with the Front Controller and their corresponding Command classes, by creating the notion of a "sequence" that can code generate stub classes for the Event and Command. Cairngen will also make it quicker for you to start a brand new Cairngorm Flex project, by creating all the project structure, folders and template classes for a skeleton Cairngorm project. Cairngen is a server-based solution, leveraging PHP and AMFPHP to manage the code generation from templates - it may work for your workflow, and is definitely worth checking out on Eric's blog.
Though I've never used the product, I noted that WebOrb is now also generating Cairngorm code from templates as well, so that may be worth checking out if you're using WebOrb already.
The Future - Integrating Cairngorm more tightly into Flex Builder workflow
I spoke in my last blog entry, that our Adobe Consulting team are constantly balancing client and project committments, with practice and community committments to deliver best-practices, guidance and productivity tools for those using the same tools and technologies that we do every day.
As we focus on Cairngorm 3, we're also very focussed on enhancing the workflow for Flex developers who are working within FlexBuilder. We've a number of ideas that are more than simply push-button Code Generation that will yield the flexibilities and benefits that we consider from working with a Cairngorm architecture, and that will furthermore leverage the consistency and predictability of Cairngorm Flex development to assist developers in building applications with Cairngorm and Flex. That was a hell of a long sentence. It's still very early days in our development, so we have nothing to preview or share at present ... but hopefully that gives a little insight into where we're going in terms of developer productivity around Cairngorm. I'm sure the consultants who have this work as their practice targets will release more information, or even previews, as and when they have something ready to share.
If I've missed any other code-generation or general Cairngorm productivity tools in my roundup, please feel free to add them here in the comments.
But hopefully that shares the current working practices within Adobe Consulting, and gives you some confidence in your own approaches.
Posted by swebster at January 8, 2007 11:40 PM
Trackback Pings
TrackBack URL for this entry:
http://weblogs.macromedia.com/mtadmin/mt-tb.cgi/8243
Comments
I'm glad you mentioned Together because that was my favorite UML tool, but I never used it for code generation though. From my personal experience, code generation only works well if you start a project from scratch. However, I found reverse engineering code into UML was extremely useful for reading code or refactoring. I wish flex builder could generate UML based on AS. It shouldn't be too difficult considering eclipse has a very sophisticated diagram framework.
Also, like you mentioned, I find DAO layer generation is the one exception where code generation is actually useful.
Posted by: Zee Yang at January 9, 2007 02:55 AM
If you're looking at adding IDE support for Cairngorm, the IDE code generation support provided for Struts application development in IBM's Rational Application Developer 6 is a good example. (This tooling is well documented in the RAD6 Programmers' Guide Redbook.)
Posted by: Graeme Harker at January 9, 2007 10:30 AM
I normally draw Class Diagrams in my projects. On the current project, there are so many classes and fields on the diagram, that creating the relational database, the value objects, and the DAO classes, is an absolute pain that is taking about 30% of the coding time of the project (not including future needs for refactoring).
I somehow feel that when i'm creating this kind of code, i'm doing something without a point - converting relational data to objects, and vice versa? I started using Flash Remoting instead XML to avoid the need of having to convert objects to XML, and XML to objects. But i still have to do the same with relational data? :|
I made a fast research on OODMBS (Object Oriented Databases etc), to conclude that this would be definitely the best option if current implementations weren't so much expensive (or if the open-source ones were more mature). So I have to stick with some ORM tools like Hybernate, or write the code myself.
In my point of view, after requirements capture and architecture design, implementing a project should imply creating only the code specific to that project: creating the data model; creating business rules; exposing services; creating the user logic (the views). But we still need to spend a lot of time with code non-specific for the project, like DAO. Which is also code that in the future can create some barriers and time consumption during refactoring, when requirements change, or new features are needed.
Anyway, the situation i am describing applies for server-side code (except for the client-side VO's), so this may not be in context for future Cairngorm's code generation tools. But it's still a problem that we, developers, have to deal with everyday.
It's good to know where Cairngorm/FB are heading! :)
(sorry for my english - portuguese is my mother language :))
Posted by: João Saleiro at January 9, 2007 01:49 PM
Did you see that the WebORB lads are claiming to have Cairngorm 2.1 code gen support in their latest release?
Posted by: Graeme Harker at January 22, 2007 05:51 PM
BTW, Ruby on Rails Cairngorm Generator is released by Ilya Devers (with WebOrb support)
It does:
* Take your application name and create typical Cairngorm structure, including modelLocator, frontController, services.mxml and application itself. You can also set the package structure.
* Create (server) delegates.
* Generate Cairngorm Commands, Events and comments.
* Create standalone events and value objects (though author acknowledges that it could make more sense to create VOs based on model classes).
* Include generator for WebOrb Service class.
You can download this Ruby on Rails Cairngorm Generators set from Google Code: http://cairngorm-rails-generator.googlecode.com/files/cairngorm-rails-generator.zip.
So Rubyists have made a good step forward.
(Also, I've posted other info I know about RoR + Cairngorm Generators in my blog, http://flash-ripper.com/en/2007/ruby-cairngorm-rails-generator-is-released/).
Posted by: Rostislav Siryk at January 30, 2007 03:51 PM
I'm hugely interested in this topic.
Posted by: Chris Charlton at February 6, 2007 06:15 PM
Did you see that the WebORB lads are claiming to have Cairngorm 2.1 code gen support in their latest release?
Yes! that's fantastic.
Posted by: Consulting Engineer at February 24, 2007 09:01 PM
It's good to know where Cairngorm/FB are heading!
Posted by: pearl-jewelry-wholesaler at March 6, 2007 04:31 AM
It's good to know where Cairngorm/FB are heading! :)
Posted by: pearl-jewelry-wholesaler at March 6, 2007 04:31 AM
http://blog.thinkingdigital.org/?page_id=4 <--- have a look here. this guy seems to be on the right track...
Posted by: Michael Jones at April 14, 2007 05:11 PM
I think code generation might be good for new users of Cairngorm, but I really feel you are barking up the wrong tree here. Why don't you just build all this boilerplate code into the framework and enable programmers to just configure CG instead? Just like you do when you create a Spring MVC application. That would make all the code generation and wizard stuff obsolete.
I feel that this is the one thing that I would like in Cairngorm, because it would make for a faster and better way of building applications.
And of course the most important thing missing when you develop Flex applications is the refactoring support you come to expect from _any_ IDE...but I guess that is beside the point.
Posted by: espen at April 24, 2007 12:08 PM
Hiring Flex Architects & Developers - Cairngorm - Direct hire - Contract - Telecommuting creynolds@dawsoncareers.com
Posted by: Catherine Reynolds at June 25, 2007 08:02 PM