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?

Well, a lot depends on how you built your Mach II application. If you built a service layer that is independent of the framework that orchestrates actions taken against the model and then you built one or more listeners that mostly just delegate to that service layer, you'll be in good shape. But I'll bet money you didn't do it that way...

I'll bet you have core business logic in your filters and listeners. I'll bet you have decomposed listener operations into private methods within the listeners... that take MachII.framework.Event type arguments and therefore contain calls to arguments.event.getArg(). Why am I so certain? Because it's so easy to fall into that trap - because the alternative is, frankly, a bit tedious and involves quite a lot more typing.

Another reason that I'm so certain you've fallen into this trap is that, despite my recommendations on listeners and models developed for our own applications, we've done it too.

Yup, right now I'm analyzing a couple of applications that we built back in 2003/2004 and have hardly touched in about eighteen months - applications that we want to put Flex front-ends on - and I have to admit it's a bit painful. I'm going to have to retrofit remote facades onto these applications and either heavily refactor some of the filters and listeners so that they have a cleanly separated model, which will require completely re-testing every aspect of these happily working production applications, or simply duplicate enough listener code into my facade to achieve the functionality my Flex applications require.

Don't think it won't happen to you! I guarantee that you'll find yourself putting a Flex front-end on a legacy Mach II application at some point and you'll wish you too had done a better job of separating your business model from your listeners!

Oh, and don't think I'm just picking on Mach II - this is a trap Model-Glue developers will likely fall into as well I expect, although tempered by the later uptake of that framework and the more experience we all now have building better CFC-based applications (right?). Of course, if you're religiously using ColdSpring to manage your service layer, you probably don't have much business logic in your controllers / listeners. Another good reason for using ColdSpring!

And, yes, this means that I'm laying the groundwork for some public-facing Flex 2 applications on adobe.com in the not too distant future.

Yeah, I'll definitely be blogging some of my findings and experiences about this. It'll be a while tho' and it'll be very circumspect until our new "stuff" is actually out there in production...

Good luck on creating your Web Service front end - I hope you'll blog your experiences for others.

Matt Woodward, nice to see even hardcore Mach II developers stepping up and admitting to the same mistakes!

I've been listening to a lot of Helms and Peters "Out Loud" lately (catching up) and they hammer this point home over and over again: the framework is just the glue, the model is the important part of the code (and the view is the important part of the application - because that's what the client sees). If we build our views as a prototype to get signoff with the clients and then write test cases and then write model code against those test cases and then glue things together with a framework, we'll be in better shape.

jroller.com/page/kwiersma