I had some information ready to be posted here when I submitted my entry into Ray's Best of CF9 contest, but he covers it pretty well in his review post; and he was kind enough to host the video on his S3 account. I've also posted the video on my Vimeo account, so here it is again for reference:
You can download the source code here. Unfortunately, I haven't found any more time to continue working on this; and I have to admit that as cool as the CFaaS feature is, I'm not terribly motivated to go further with this mail client because I know it will eventually get canned. Why write a mail client when you use Outlook every day?
So it was a fun way to play with Flex 4, the latest Swiz build at the time, AIR, and CFaaS; but I don't think I'll bother continuing to mess with it.
I'm betting that Sean Corfield doesn't need me to evangelize his software to garner attention for it. I'm a relative nobody — standing in his shadow, so to speak. But it's good, so I feel compelled to share my experience with you.
Disclaimer
I should start by saying that I am generally pro-framework. They aren't a silver bullet, and each tries to solve some set of common problems in varying ways, so each has its place; but for larger projects, or projects written collaboratively by a larger team, or projects that plan on having a long life-span requiring some level of maintenance, I've found front controller frameworks to be quite useful. Not only that, but specialty frameworks like ColdSpring and Swiz have been incredibly useful and eye-opening to me. I suspect that Transfer would be on that list too, if I'd had time to learn it yet.
So, if you're anti-framework, you may not agree with my reasoning. Or, for that matter, depending on your reasons for being anti-framework, you may really agree with me a lot.
Introduction
FW/1 is a front controller framework whose primary strength, in my opinion, is its simplicity. Too often, framework authors (or authoring teams) get swept up in features that only a percentage of the framework users will use, causing needless bloat for the remaining users. FW/1 seeks to obliterate bloat, and I think it succeeds masterfully.
Why I Love It
I won't drone on and on about how it works. Some documentation is available (and getting better all the time), and the framework itself is only 626 lines of code as of this morning's release — most of it well commented — so if nothing else, you can look at the source to figure things out. But what I will tell you is why I love it.
Due to feature bloat, many other frameworks load lots of extra objects (CFC's) and we have to face facts: Although leaps and bounds have been made in improving object instantiation time with ColdFusion 8 and again with ColdFusion 9, it's still a noticeable detriment to the page load time for the user that spins up the application for the first time since it timed out; and that time scales up with the size and complexity of your application. More events means more config, which means more load time — even if it's spread throughout the application life cycle with lazy loading. To put it bluntly: things are getting better, but they're just not quite there yet. (I'm told Railo has excellent object instantiation times, but don't have any experience to draw on.)
Server.cfc, added in ColdFusion 9, will give us a way to spin up the application before the first user accesses a page, but what it doesn't do is keep the application from timing out. That may not be a problem for a site with hundreds of thousands of users, but for a start-up company, or even just a simple blog application that makes use of a framework, that load time after application timeout can be so freaking annoying. Even though I consider myself pro-framework, that load time is what I would consider my number one complaint about the front controller frameworks I've worked with. On nice hardware with lots of memory and a fast CPU, it may not matter much, but for an independent developer on shared hosting it can be a nightmare. In the past I've written scheduled jobs from two different servers to ping each other and keep the applications from timing out, but that is far from ideal.
All of this griping has just been to make the point of how awesome FW/1's simplicity is. It's 1 object: Application.cfc. For cleanliness and separation purposes, it's written as a base class from which you extend your application's Application.cfc, but for all intents and purposes, you could rename Framework.cfc to Application.cfc and run your application along side it with a few lines of configuration. That's it. When my application starts, it just starts.
Speed is a feature, and FW/1 nails it. In addition, I'm in love with its simplicity. If something's not working quite right — or as is more often the case, if I've misunderstood the order that things run — I can dive right into the code of the framework and figure out why I'm getting an error within a few minutes. There are no sprawling api methods to keep track of; only one data construct: "rc" (request context) which passes form, url, and service-result data between the controller and the view.
No XML. None. Nada. Zilch. I had at one point entertained the idea of writing a Model-Glue plugin, or fork, that would allow configuration to be specified as CFML or as JSON, but I never got around to trying it. Now, with FW/1, I don't have to write any XML.
I've yet to explore the layouts feature, but I know I will, and I'll be happy to have it. I know it can optionally integrate with ColdSpring, and I'm happy about that. And, with a few minor exceptions, that's about all it does. And I'm thrilled about that.
Congratulations to Chris Scott — manager of the Philadelphia CFUG, and project lead for ColdSpring — and the rest of the ColdSpring team. Looks like a job well done!
Best Practices is something that I don't think anyone, anywhere,
ever gets 100% right. There's no "right" way to do everything. But
we're striving to do things better all of the time, right?
For example, in the ColdFusion world we have Unit Testing frameworks like MxUnit, CFUnit, CFCUnit, and Selenium. I know Selenium isn't just for CF, but it does integrate nicely! Test-driven Development is all the rage these days, and while that's a good thing it's not for everyone and certainly something very difficult to "get right."
Consider that in a large project — one with 1,000 test cases — if you refactor some code that affects 10% of your tests, you have to re-write 100 test cases. This isn't to say that TDD is a bad thing… far from it! Just that there is no silver bullet, and that you always have to be thinking ahead to try and do things right the first time, and not repeat yourself.
This brings me to a change I recently made in Grub.
Grub uses the Model-Glue framework to, as I like to say, "code less and do more." In Model-Glue's XML config, we have an <include> tag that allows us to separate our config into logical sections to keep maintainability high. But did you know you can do the same thing with your ColdSpring XML config?
Well, not with out-of-the-box 1.0… You have to download the Bleeding Edge Release, here. The feature was first mentioned in November of 2006, when Jared announced that he had written it. It was then blogged by a bunch of other ColdSpring users, but I don't think any of them mentioned that it wasn't yet included in the official release except Mark Drew, and even then I don't think I picked up on that fact until well after my second or third reading of his post. I ended up reading this bug report that clued me in, after about an hour of trying to figure out why the necessary method wasn't where it should be.
After you download the BER and update your local copy of ColdSpring, you can add lines like the following to your beans XML:
I used this code to separate out my Model Glue config — which will be constant in every environment, but different between them (debug, reload, allow event generation in dev; no debug, no reloading, and no generation in production or staging) — from my bean definitions, which change frequently as I work on the applicaiton. Now, with my ANT build script, I can build and deploy my project without ever thinking about config, and I know it will always be right because it will never change without me doing so manually.
I'm somewhat surprised that over a year has gone by and it's still not included in the official release. This means that I'm currently using two unreleased frameworks in Grub (the other being the Model-Glue 3 RC), and that I am going to have to include them both in the download to make it as user-friendly as possible.
