Here's what I said in response:

[More]

We've worked hard to make cf.Objective() 2008 a "must see" event. We have a number of firsts this year that we're very proud of:

• The public release of Open BlueDragon on May 3rd!
• The public unveiling - and Alpha - of Model-Glue 3: Gesture!
• The public unveiling of Mate, the new Flex framework from AsFusion!
• The first conference to feature the latest rising star in the frameworks world: ColdBox - with an introductory session and a two hour, hands-on advanced workshop!
• The first public information about Swiz, the new Flex framework from Chris Scott of ColdSpring fame!
• Speaking of Chris Scott, we're the first conference to feature a two-hour, hands-on workshop for ColdSpring!
• We're also the first conference to feature a two-hour, hands-on workshop on agile development for ColdFusion developers by the leading light in automated process & testing, John Paul Ashenfelter!

If you're a Mach-II user - or thinking of using Mach-II - you might also be interested in the pre-conference classes.

We hear a lot of talk about using individual Java objects within ColdFusion but the reality of enterprise development is that entire subsystems tend to built entirely in Java. Software teams that serve the enterprise often build large, complex systems using Spring and Hibernate. How do you go about using ColdFusion with such systems? I haven't seen any presentations on this subject so I was pleasantly surprised when I started reviewing Andrew Powell's slide deck to find that he was focusing on how ColdFusion can provide the web front end to enterprise class Java systems.

He introduces Spring (the Java version) with a demo and then introduces Hibernate (the industry standard ORM for Java), again with a demo. After that, he will walk you through solutions to the problem of connecting ColdFusion on the front end to Spring on the backend and, using Mach-II as an example, he then shows how to create an MVC web application that allows you to leverage the entire Spring-powered, Hibernate-persisted Java backend.

If you work along a Java team - or you are considering using more Java for your backend systems - this talk will provide you with a lot of good information about how well ColdFusion plays in this space.

I wanted to let folks know what a great job Matt and Peter are doing with the framework. Mach-II 1.5 was a very impressive release with a lot of new features that help you manage large-scale application development: modules, includes, subroutines, extended property data type support, SES URL support and bindable property parameters.

[More]

In Mach-II, inside an event handler, you notify a specific listener to execute a specific method. In Model-Glue, inside an event handler, you simply broadcast a message and any listeners that have been declared for that message are executed automatically by the framework.

[More]

Model-Glue has come on in leaps and bounds - the rearchitecture based on ColdSpring, the scaffolding infrastructure, the integrated support for Reactor and Transfer for "generic database messages". It's very impressive. And now we're got the beginnings of a Flex version, which is very promising.

Now that I'm consulting and have a number of clients, I'm encountering Mach-II quite a bit and looking at the 1.5 release. I've mentioned in the past that I think 1.5 looked quite impressive (when Peter Farrell gave the "what's new?" talk at cf.Objective(), for example). Recently, I've been making recommendations for frameworks for clients and finding myself recommending Mach-II for some clients, mostly due to the new features in 1.5. For some of the sites my clients are trying to build, the modules, includes and subroutines really do allow you to build much larger, much more modular sites than earlier versions of Mach-II.

The extended property semantics in Mach-II 1.5 are also very nice, allowing you to specify structured configuration data - including full-on CFCs - as well as allowing property values to be dynamically substituted into parameter values throughout the configuration.

I still don't really like the direct invocation model (with <notify>) compared to Model-Glue's broadcast / listener mechanism, but the other features are pretty compelling.

One thing I have seen mentioned, but cannot find, is Peter Farrell's new ColdSpringProperty CFC, to replace the old ColdSpringPlugin. Anyone know where to get a copy?

Brian Kotek has a great post about data vs content in the context of AJAX and frameworks. He emphasizes the benefit of having your model in CFCs as the easier way to expose data-centric functionality to AJAX and notes that for data calls, you should not be trying to go through the MVC framework. It's a good read.

As a framework developer, it can be really hard maintaining complete backward compatibility as you move the architecture forward and there are often parts of the framework that you don't want to have to maintain indefinitely.

It's good to see the Mach II team being so public and forward-looking about the framework so that users can plan to move forward as well.

Next up I covered the Fusebox 5.5 release which is currently in limited Alpha with a public Beta planned in July (as soon as we can get enough documentation together on the new features). I also announced publicly that providing a migration path for Fusebox 3 was on the roadmap (for Fusebox 5.7 probably).

Matt Woodward (and Peter Farrell) presented Mach II 1.5 which is in Beta right now, and the new website. He also talked about plans for their 2.0 release (but didn't go into specifics).

Next up was Chris Scott, who said that an official 1.2 release would appear within a few weeks and then they would be working toward a 1.5 release. This will be the last release of ColdSpring that will run on CFMX 7 - ColdSpring 2.0 will require CF8 because they want to take advantage of cfinterface and onMissingMethod() to make ColdSpring faster (and simplify the core files).

Last up was Doug Hughes who assured us that Reactor would hit an official 1.0 release as soon as the documentation was complete. Ah, the dreaded documentation...

Kudos to the Mach II team for what has clearly been a lot of work behind the scenes!

Anyway, I figured I'd put a note out based on the answers I've been giving these folks.

First off, Mach II is alive and well and getting some serious attention from Matt Woodward, Peter Farrell, Kurt Wiersma and others (like Dave Shuck who is taking on the role of Mach II community manager).

Second, Mach II is a mature, stable framework so you should not expect to see a steady stream of changes. That would make life hell for developers trying to use the framework! One release a year is probably a good pace for a framework once it is well-established.

Third, a public beta of Mach II 1.5 should be released at CFUNITED along with a brand new web site. Hopefully that will stop the questions.

CFUNITED will be a major event for frameworks: Mach II 1.5, Model-Glue 2.0 and a public beta of Fusebox 5.5 (I hope!).

The example blog application created for the MAX frameworks debate is going to be released soon - as an example of a full blown application built with Mach II, Model-Glue and Fusebox (as well as ColdSpring in the Mach II and Model-Glue cases). Definitely something to look at, no matter which framework you use (or not).

Matt is also working on a detailed comparison of Mach II and Model-Glue which should make interesting reading.

He is also producing a (much needed!) update to my original Mach II development guide. Big thanx for taking that so I won't have to feel bad about how long it's been since I updated it. My excuse? Well, I haven't worked on any Mach II applications for quite a while...

As someone who has contributed extensively to Mach II, Model-Glue, Fusebox, ColdSpring and Reactor (phew!), I would like to step up and defend Joe's decisions - he's done a sterling job, sticking to his vision for the framework and has been very clear about what should be in the framework and what should not. As a framework developer myself, I can tell you it's a rocky road. The "community" deluge you with requests for all sorts of features and you have to stand firm and defend your vision. None of the popular frameworks are "kitchen sink" efforts - there are countless feature requests that have been denied by the framework authors.

I've requested enhancements to all these frameworks. Some of those requests have been implemented but most have been denied. Even as lead developer on one of the Mach II releases, some of my suggested enhancements were turned down (and some of the changed Peter implemented in Mach II were reverted as inappropriate for the framework).

When I built Fusebox 5, I was deliberately very conservative about what went into the framework and what didn't. I implemented a few things the community really wanted that I didn't think were great ideas but I also did not implement several things that I thought were great ideas that the community weren't very interested in.

Fusebox 5.1 will be a fairly conservative enhancement release. Fusebox 6 has more scope for adding features but, even so, backward compatibility will be maintained and the addition of features will be strictly controlled but community-driven.

I don't know how community-driven Mach II is. I don't think it has a public bug tracker (Model-Glue, Fusebox, ColdSpring and Reactor all do). I get the impression that Application.cfc support was added for coolness (the other frameworks have taken great pains to remain compatible with CFMX 6.1 and equivalent competing ColdFusion engines).

And then you need to put a Flex front-end on your application. That means you need to expose your model as a set of remote methods. If you got your application design right, that'll be easy: just open up your model CFCs and change the access attributes and you'll be done, right?

[More]

First off, while I think the tests are interesting, I've always been one to say don't worry about performance too much because "fast enough" is almost always sufficient. Very few websites get the sort of traffic to need heavy load testing and tuning, frankly, and as we know there are some very high traffic sites out there running on various frameworks. macromedia.com runs (about a quarter of its applications) on Mach II and the performance under load testing met all of our criteria.

My comments about the tests Webapper ran were meant to say:

• It's no surprise Fusebox is "faster" because it is more of a compiler than anything else (the framework doesn't really "do" anything at runtime, once your XML is compiled to CFML)
• I was pleasantly surprised that Mach II was not slower than a hand-coded CFC-based application - a lot of people complain about the "overhead" of Mach II but this shows that is not necessarily true

The point of the original (Webapper) article was that JVM tuning can have a dramatic effect on performance, as can Trusted Cache.

Probably the biggest news in this release is the introduction of resultArg= and contentArg= as the new "best practice" to avoid using the request scope.

There is also a <redirect> command (added to the XML language) so that you don't need to write a filter for simple redirects.

Keep an eye on Peter Farrell's blog for hints and tips on using the new release!

The #coldfusion channel is often all over the shop and sometimes politically incorrect in the extreme but the framework-related channels are generally much quieter and much more on-topic.

We will be meeting at the Portland offices of Schoonertech - directions are now on the PDXCFUG website.

Don't forget that there are also full-day classes being run on the Wednesday before the conference (9/28):

• (FB103 Intro to Fusebox - Simon Horwith - cancelled)
• FB301 Advanced Fusebox - Jeff Peters
• (MT101 Mach II - Hal Helms - cancelled)

I'm going to be in Salt Lake City so I'll miss this year's conference which I'm fairly bummed about - it really looks like a great lineup!

Only a week left to get the early bird price too so hurry up and register!

Read Ray's enthusiastic response to Wayne's blog posting about the technique.

This should apply to other frameworks that use XML configuration files but I haven't tried it.

And, no, I will not be there this year - it clashes with a cat show in Salt Lake City so I'll be on the road from California to Utah while the conference takes place!

I'm back from a long weekend away and I'm very gratified to see several people writing good, reasoned, blog posts explaining why Peter is wrong. Although Elyse seems to side more with Peter.

Those who know me will be well aware that I'm stirring the pot to provoke discussion and to make people think for themselves about their technology choices. That's one of the main drivers behind my "Frameworks: Fusebox or Mach II?" talk (Wednesday 6:10pm and Friday 10:40am at CFUNITED)...

Now the question in my mind is whether I should "promote" Model-Glue from the notes (for folks to read after downloading the PPT) to content in the actual presentation itself? In some ways, most of the comparisons (between Fusebox and M**) would turn out the same but there are some interesting differences as well. Thoughts?

The first thing that kept tripping me up was that Mach II uses event= for the event-handler name but Model-Glue uses name=. It's a hard habit to break as I repeatedly found out! Overall, the Model-Glue grammar is more verbose because of its nested structure but the visual effect is a much less dense XML file: Mach II's flat syntax means event handlers have a sequence of single-line XML tags; Model-Glue has a broadcasts section containing indented message tags followed by a views section containing indented include tags and a results section containing indented result tags. The nesting and the simpler tag language leads to more whitespace and more vertical layout which, in my opinion, is easier to read.

A corollary to that is that Mach II lets you intersperse view-page tags, notify tags, event-arg tags and so on which can make it a little hard to follow exactly what is going on in a complex event handler. Model-Glue makes you list your broadcast messages first, followed by your view includes, followed by any continuation events (results). That means you have a clearer separation of control logic and presentation than Mach II allows. Model-Glue uses the event object consistently as the data bus so it doesn't suffer from the event-arg injections that are necessary in Mach II (unless you're using a custom Mach II invoker to store results directly in the event object!).

Shifting the configuration of Mach II's listeners out to config beans in Model-Glue meant that I could cut the number of listener declarations from 25 to just 6 controllers. Then instead of notifying one of 25 listeners to call a method, I was able to send a parameterized message to one of just 6 controllers - the parameter specifying which config bean the controller needs to use. Since the config beans are singletons, they can maintain the state I was previously maintaining in all my separate listeners. This pretty much turned my previous architecture on its head because the configuration is now a dynamic attribute of each controller invocation rather than a static attribute of each listener declaration. Since I don't actually have to preserve the URL structure, I can make further simplifications to the application structure now - but for now the benefits of moving the configuration out of the main line are enough.

One stumbling block I hit was where I was running some business logic, generating a view and then using the rendered view in some more business logic. I was emailing the intermediate view results to interested parties. In Mach II, because you can mix notify and view-page tags, it's pretty easy to perform business logic on the result of a view rendering. While the mixture of business and presentation logic leaves a bad taste in my mouth, there appears to be no easy way to deal with this in Model-Glue and it still feels like there should be... My workaround was to duplicate the view into a cfsavecontent within a controller since it was such a simple view (fortunately). I'm not very happy with that either.

Coming back to the event object issue, Model-Glue's consistency means that every controller method gets passed the event object and is expected to return it - result values are added to the event object rather than being returned from controller methods. The downside is that controller methods tend to conclude with:

There's no doubt that Model-Glue has benefitted from the experiences of both Mach II and Fusebox but it has also added its own unique elements. Consistency and simplicity are key drivers for Model-Glue which means you sacrifice some power and expressiveness. As always, it's all about tradeoffs and you need to make the choice based on the needs of your project (and, to some extent, your own personal preferences).

As you probably know by now, I'm working on our next generation order management system. The current, live system relies on a lot of batch processes, powered by ColdFusion, shuffling, processing and generating a lot of XML files. The previous system was also batch processed but used proprietary file formats (mostly CSV - comma-separated value - formats) and was not powered by ColdFusion.

The next generation system relies very heavily on CFMX 7's event gateway system to provide near real-time data transfer between all the various IT systems. So it's mostly CFCs, all running quietly in the background.

However, even this new system will still deal with some batch jobs and, like its predecessor, it has a simple HTML user interface for certain manual tasks, mostly related to debugging and monitoring.

Since Mach II is a Macromedia Web Team standard, that's what I used to build the current administrative interface. A handful of listeners that drive the underlying order management CFCs and a handful of views that display the debugging and monitoring options and results. All of the batch jobs use Mach II URLs too and, since the batch jobs interact with a lot of servers, there are actually 25 listener declarations, even though there are only five distinct CFCs used as listeners. The mach-ii.xml file described all of the various FTP and directory structures across development, QA and production - each listener declaration represented one of the basic five listeners configured for a particular scenario. During system maintenance, the IT Operations folks would sometimes need to modify the mach-ii.xml file (changing a directory path or a password or...).

That should ring some alarm bells. Application structure / control flow should be separate from configuration data.

At first, it had been OK to manage things this way but as the number of different configurations grew, I had begun to realize that the time would come when I would need to restructure the application - in a fairly radical way, most likely.

I decided that all the configuration should be separate from the main control file and that I needed a way for the configuration to be automatically mapped to objects, for easy manipulation within the main application code.

Sounds like... a managed container... perhaps "Inversion of Control"...

Since that sort of restructuring was likely to involve touching all of the Mach II code (all the listener configuration would need to move elsewhere, as well as some basic configuration data that was currently stored as Mach II property tags), I figured that maybe changing to another framework would not be that much more work. A framework that provided a similar MVC structure but with automatically managed configuration objects. Model-Glue, to be precise.

I started the conversion Tuesday morning (May 31st) but spent most of the day planning out the design of the configuration beans that I would need, looking at how I could improve the maintainability of the configuration as well as simplify the code that used the data. I'd created the outline of one bean by close of business.

Wednesday was very productive with the bulk of mach-ii.xml rewritten as ModelGlue.xml and most of the original Mach II listeners rewritten as Model-Glue controllers. The main administrative menu page appeared and a few of the options actually worked.

Today saw the completion of the rewrite, including the tedious task of writing over a dozen very similar FTP connection configuration files! I did some unit testing and then checked everything into CVS and pushed it to the shared development server for folks to use.

mach-ii.xml file: 522 lines, 23K of fairly dense XML, 25 listener declarations.

ModelGlue.xml file: 427 lines, 11K of fairly well-spaced XML, 6 controller declarations, 5 config bean CFCs, 22 bean configuration files (710 lines, 16K of XML).

In a future entry, I'll talk about some of the issues, benefits and mindshifts I encountered during the conversion of this application.

I've already added a comment in response to several other comments there but I want to highlight a couple of observations he makes.

He draws a clear distinction between the primary application frameworks (Fusebox, Mach II, Model-Glue) and the "supporting" frameworks (Tartan, CFHibernate, ColdSpring). This is important to understand: you can use the supporting frameworks on their own, i.e., with your own ad hoc code, but they really work well when used with the primary application frameworks. Indeed, Tartan includes a Mach II listener and Model-Glue includes a Tartan proxy.

He also notes that Mach II gives the appearance of a framework that is not evolving very fast and compares it to Model-Glue, saying the latter "might very well take over". It will definitely be an area to watch closely.

More on this topic when I speak at SacCFUG, BACFUG, CFUNITED and PDXCFUG over the next few months. After CFUNITED, I'll make seven variants of a sample application available - each variant shows a different framework or a different style within a single framework.

On the choice of frameworks, Hal says:

"So, if I were working on a team with Ben Edwards and Sean Corfield, both OO guys, I imagine we'd use Mach-II. If I was working on a team with other programmers (who may be as good or better than Ben or Sean, but simply don't do OO), I think I'd choose Fusebox."

Then Jeff asks why Mach II requires OO-aware programmers and Hal gives this very good answer:

"Mach-II exposes more of its internal architecture than does Fusebox. As I said earlier, you could change Fusebox's architecture from procedural to OO and no one would notice. If you went from OO to procedural with Mach-II, everyone's code would break. The controller components Mach-II programmers create extend the Mach-II framework components."

I'm designing a new website using Adalon so I'm going through the whole wireframe, XFA, fuseactions, fuses design process and it's hard. This is just not what I'm used to.

The site ought to be pretty simple: it's a basic task manager with elementary user identification. I know how to design it from a model point of view, using an OO model design. But trying to follow FLiP to drill down from the user experience into the mechanics is killing me!

I'm trying really hard to follow the process. I keep walking through the use cases, with input and output variables being passed between fuses but it's so painful for me.

I hadn't realized how differently I think about problems - but it definitely highlights why FLiP doesn't 'click' for me.

So why am I putting myself through this pain? I'm writing a presentation that compares Fusebox and Mach II. I know how I'd design the Mach II version and I'd use a very similar approach for an OO MVC Fusebox 4.1 design. But to really get a good comparison of the frameworks, I really want to start with a 'traditional' procedural Fusebox application.

I'd be interested to hear your stories of paradigm shifts...

Read about the conversion process and the reasons why I went through yet another conversion exercise. Don't expect this to be the last word on frameworks!

Phil Cruz pointed out that 1.0.10 added get/setProperty() to ViewContext and hence you can simply say getProperty("fnlib") in a view to get your function library back.

Very elegant!

Of course, this poll is pretty heavily skewed because it represents a segment of my blog readership rather than the CF community as a whole (anecdotal evidence suggests about 6-10% of CF developers at large use Fusebox whereas my poll shows about 30-35%). Still the numbers are interesting and I'm very pleased to see so many people are using some sort of framework.

There was a discussion about which framework was best suited to which type of developer. Some folks clearly think Fusebox is easier to learn and therefore more approachable for novice developers - and I'd agree. I definitely got the impression that folks are migrating from Fusebox 3 to either Fusebox 4 / 4.1 or to Mach II, basing their choice on the skill sets of the teams they are working with.

What I want to draw attention to here is a key point in the conclusion of his Inversion of Control Containers review:

"In particular, I salute Howard for resisting attempts to twist HiveMind into something it's not - a rare quality, particularly in open source. HiveMind does (mostly :-) ) one thing and does it well."

Mike comments that PicoContainer looks like it followed the XP YAGNI (You Ain't Gonna Need It) principle and each new release seems to have haphazardly added those features which - guess what? - you did need them after all. He also comments that "Spring's just a bit took kitchen-sinky for me."

My point? Frameworks work best when they are cohesive, focused. That usually means tightly-controlled rather than being open source free-for-alls and it also usually means that the creator(s) started with a coherent vision of the whole.

So, when you're asking for Fusebox or Mach II to be opened up so y'all can contribute code, think about Mike's comments on why some frameworks work better than others.