Cliff Hall has released a new version of PureMVC with various improvements which you can read about here. In conjunction with this release, Cliff has also unveiled the Manifold Project, which provides numerous demos and ports of PureMVC to languages other than ActionScript 3. I am proud to say that I am participating in the open-source Manifold Project, and my Flex-on-Rails application, “Index Cards,” is now a Manifold demo application. From this point forward, you can keep abreast of the development of Index Cards, report bugs, and suggest new features via its Manifold project site.

Kudos to Cliff, who had to do a tremendous amount of work to pull this off. I suspect that a lot of developers will benefit from the effort.

I’ve completed the first iteration of a Flex-on-Rails application, and had a lot of fun doing so. The application is called Index Cards, and it’s designed to be a generic study aid. The metaphor is simple: on one side of the index card, you write the name of a concept that you wish to learn, and on the back you write a definition and/or description of that concept. Of course, you’ll have a separate set of index cards for each subject that you study, and within each subject you will further divide your index cards based on topics or categories. You put all of the cards for each topic or category in a rubber band to keep your cards from becoming disorganized. For example, if the subject you’re studying is elementary statistics, you might have one rubber band to hold cards with descriptive analysis concepts, another rubber band for probability, and so on.

Unfortunately, I haven’t lined up Rails hosting as yet, so I don’t have an online demo to play with. However, you can download the source code here. Please let me know if you have any feedback (criticisms, suggestions, kudos, etc.). Most of the code is still uncommented, so feel free to ping me with any questions as well.

In addition to being my first significant Rails application, this is also my first use of the PureMVC framework. I will admit that this slowed me down much more than expected, as I had some trouble wrapping my mind around PureMVC. However, now that I’m starting to get the hang of it, I think I like it. I will have a better idea of how much I like it when I start adding functionality. I’ll be posting comments here as I build out the app, so stay tuned.

As it stands, the application has the basic required functionality: you can create, update, and delete index cards, and you can flip through the cards to study them. However, I plan to add (at bare minimum) the ability to study only one rubber band at a time. I also hope to add user management and login functionality so that there could be multiple users of the same instance, as well as different ways of studying with the index cards (multiple choice etc.).

Below is a list of resources that were instrumental in getting me to this point.

Rails:
Agile Web Development with Rails (of course) by Dave Thomas, David Heinemeier Hansson, et al
Rolling with Ruby on Rails Revisited by Bill Walton and Curt Hibbs
Integrating Flex 2 and Ruby on Rails by Derek Wischusen

PureMVC:
PureMVC Best Practices by Cliff Hall
Cafe Townsend demo by Michael Ramirez (This is an adaptation of the Cairngorm demo for PureMVC)

After attending my Cairngorm presentation at the 2007 FlexManiacs conference, a co-worker (who happens to be an ardent Rails developer) expressed some concern that Cairngorm seems to be overly complex. He thought that perhaps there was too much abstraction for the sake of abstraction, and mentioned that there seemed to be a lot of small files, some of which perform parallel tasks. I took his concerns to heart, and decided to re-analyze Cairngorm with a more critical eye.

Recently I began learning Ruby and Rails myself, and I have been very impressed with what I’ve seen. So far, Ruby does indeed appear to be an exceedingly attractive language, and Rails is a massive labor-saver. However, I have learned some things that make my co-worker’s concerns about Cairngorm appear to be a little ironic.

When you tell Rails to create a new application, it creates an application directory with no less than 37 subdirectories (using RubyStack, which runs on Ruby 1.8.6 and Rails 2.0). Scattered among these directories are 49 files - all before you write a single line of code. At this stage, the application does absolutely nothing except display an HTML page welcoming you to Rails. This is far more than is required by Cairngorm. In fact, here’s an example of a complete, fully-functional, and non-trivial Cairngorm application that has only 67 files and 21 subdirectories:

At first you may think that I am comparing apples to oranges, and I will readily acknowledge that Rails does some things that Cairngorm doesn’t (most notably, Rails helps you to manage your database tasks). However, Rails and Cairngorm are both MVC-based frameworks for building Web applications, so in principle their reasons for being are really pretty similar.

In fact, the Rails workflow is in some ways similar to the Cairngorm workflow. For example, adding new functionality in either framework often involves creating a few simple files (and perhaps adding a line or two to some existing files) with the result that both frameworks lead to multiple files performing parallel tasks. In either framework, modifying the existing functionality is frequently a matter of making simple changes to several related files (e.g., a Controller file, a Model file, a View file, and a Test file). While jumping from file to file may seem inefficient to the uninitiated, in reality this workflow is great for productivity. For one thing, it’s much easier to place and track a few simple pieces of code located in a few small, intuitively named, and logically organized files than to manage a single complex piece of code in one monolithic file - especially with modern IDEs and text editors, which make it a snap to work with multiple open files simultaneously.

There are other benefits in addition to the productivity boost, of course. In either framework, for example, you can usually modify or even remove an existing piece of functionality without having any impact on the rest of your application, because the change only affects the files that are directly involved.

Anyway, what’s the point of this comparison? The point is simply this: having lots of small, well-named files with very specific functionality organized logically in several directories is not necessarily a bad idea. While at first blush it may seem daunting, in the long run it can help to save a lot of time and promote higher-quality software.