This year's cf.Objective() is offering SIX pre-conference classes! You can choose from Building Secure CFML Applications, ColdBox: 100 Training, Developing Applications with ColdFusion 9 ORM, Getting Started with Flex / AIR Development, Mach-II / OOP from the Ground Up, Rapid Development with Model-Glue 3! Wow!

Some of these are one-day courses (Wednesday April 21st) and some are two-day courses (Tuesday April 20th and Wednesday April 21st).

An official beta of Model-Glue 3 aka Gesture was announced yesterday. You can read about the new features in MG3 on the wiki (all new Model-Glue documentation!).

For folks attending cf.Objective() 2009, there will be a Birds of a Feather session at 8pm on Friday night, led by Dan Wilson, which will introduce the beta and discuss the new features.

As the conference draws near, we're finalizing speakers for the final few slots in the schedule and the Saturday schedule is now completely fleshed out with Mark Drew's morning session being focused on Model-Glue (in the absence of Joe Rinehart this year, Mark is covering Model-Glue and Brian Kotek is taking over Joe's open source Java in ColdFusion talk) and two exciting new topics in the 3pm slots: Samer Sadek will be explaining how to construct scalable services for Flex using ColdFusion and Pete Freitag will be looking at the CF Administrator and showing how to improve the security of your server.

We still have three speakers marked "TBD" (Working with Transfer, Service Oriented Architecture and Adobe's 'Flex topic') but we expect to announce those in the next few days.

There are still two BOF slots available for RIA topics if anyone wants to lead a session!

Since Mark Drew was also covering cloud computing in London, we've decided to offer a version of my framework comparison talk instead.

I'm looking forward to that first week of June despite the crazy travel schedule (I arrive Sunday afternoon and fly back the following Saturday, hopping from Edinburgh to Heathrow on a horribly early flight).

One of the neat features of the Railo Administrator console is that you can easily install pre-packaged applications with just a few clicks. As part of my recent presentation comparing application frameworks, I installed ColdBox, ColdSpring, Mach-II and Model-Glue via the Web Administrator. There are a couple of "gotchas" about the current default settings for those installations that I wanted to cover in a blog post.

[More]

Last night I presented to BACFUG on ColdBox, Mach-II and Model-Glue. I just posted the recording of the presentation to Charlie Arehart's UGTV. I've edited the recording to remove some of the chatter at the beginning and end which is why it will seem to jump in without my usual biographic introduction and cuts off at the start of Q&A.

BACFUG meets tonight in Alameda, hosted by Planitax (thank you!), and the featured speaker will be me!

I'll be looking at ColdBox, Mach-II and Model-Glue - talking about their similarities and their differences - and showing demos of each framework.

Please see the event listing on Adobe Groups for more details and to RSVP (you must login with your Adobe ID to RSVP!).

Back in Summer 2005, Peter J. Farrell asked is Mach-II dead? There had been very little action on the framework for ages and Model-Glue was the "new kid on the block" and was surging in popularity. A few days later, he proclaimed Mach-II is dead as a call to arms. The result was that Matt Woodward took over the Mach-II project and Peter became lead developer. Since then Mach-II has gone from strength to strength with 1.8 in development now and 2.0 in the planning stage.

[More]

Liz has announced the first round of topics for CFUNITED 2009. It's an interesting mix of speakers - some old, some new - and a broad spectrum of subject matter.

After CFUNITED 2008, Liz has promised lots of changes and improvements and we already know that the venue is something special and an all-in-one location (addressing a bit complaint about the last few years' conferences). One of the new changes for 2009 is that a quarter of the content will be Flex/AIR related, acknowledging the growth and increasing relevance of these technologies to ColdFusion developers at large.

Some of the highlights (from my point of view) of the topics announced so far:

• Flex development with the Swiz framework - Chris Scott
• Railo Open Source - Gert Franz
• Groovy for ColdFusion Developers - Joe Rinehart
• iPhone Apps + Adobe ColdFusion - Josh Adams
• ColdFusion, Model-Glue, Hibernate, Spring, and Groovy - Ray Camden
• AIR: Building Desktop Applications with Flex 3 - Rob Rusher
• Hack Proofing ColdFusion - Shlomy Gantz

Definitely not your father's CFUNITED!

Important: you must RSVP via the BACFUG website. We have a hard limit of 47 attendees - if you do not RSVP, you may well be turned away. If we get close to 47 RSVPs, I will post again on my blog!

MAX 2008 will be upon us soon and this year it coincides with our regular 3rd Wednesday for BACFUG. Accordingly, we have a special meeting with two presentations by speakers who are in town for MAX!

Bill Shelton and Marc Esher - creators of the awesome MXUnit testing framework - will be presenting "Unit Testing with MXUnit". Unit testing talks have proved very popular at BACFUG in the past and MXUnit has really raised the bar in terms of features and tools so it will be great to have the framework's creators speaking at MAX.

Our second presentation will be related to Model-Glue 3 "Gesture" and will again be the framework's creator, the amazing Joe Rinehart. Joe has hinted that he will be tailoring the talk toward integration with powerful Java technologies, along the lines of what we have achieved at Broadchoice.

BACFUG is free and open to everyone - both regular locals (who may or may not be attending MAX) and all those CFers who are in town for MAX! However, we need you to RSVP on the BACFUG website so that we can figure out numbers and book a large enough room!

Today was our official launch, just in time for MAX! Now anyone can download the Broadchoice Workspace AIR application and create a 30-day trial account.

Commercial use will be just $99/user per year with educational licenses at $49/user per year. Registered non-profit organizations can get free licenses.

If you're also a Salesforce user, you'll love the integration between groups in Workspace and your company's Salesforce account, allowing you to see open opportunities directly in the Workspace and create collaborative spaces based on opportunities so that you can work with your non-Salesforce peers on closing deals!

Working with Brian Kotek, Joe Rinehart and Ray Camden on this application has been a wonderful experience. We've all learned a lot from each other as we've learned a lot about Flex, AIR, Groovy, BlazeDS, Spring, Hibernate and integration with CFML via Model-Glue 3 (Gesture) and ColdSpring!

Also, for Workspace users on-the-go, there is an iPhone-compatible web application (with plans for full Blackberry support by year end).

I just made another pass over my MAX schedule to finalize my choices and thought I'd post my planned list of sessions so folks will know where to find me:

• Monday
  • Opening General Session
  • Adobe Roadmap: Enterprise
  • Flex Architecture Face-Off - panel
  • Real-Time Collaboration Apps with Flex and Cocomo - Nigel Pegg
• Tuesday
  • Mixing Open Source and Commercial Software
  • General Session
  • Adobe@Adobe: IT Innovation
  • Developing Rich Applications with jQuery and Adobe AIR - John Resig
  • The REST of SOA
• Wednesday
  • Advanced Patterns for ColdFusion Test Automation - Bill Shelton / Marc Esher (MXUnit)
  • Building Real-Time and Collaborative Applications with Flex and BlazeDS
  • Event-Driven Programming in ColdFusion - an updated version of my session from Scotch on the Rocks and CFUNITED
  • Cocomo Deep Dive: Building Social RIAs with Flex + Adobe Hosted Services - Nigel Pegg
  • Developing Enterprise ColdFusion Applications - Joe Rinehart

As I was updating my schedule, I noticed that several of the ColdFusion and Flex workshops are already sold out - good to see so much interest in those! I was originally going to Dave Watts' "High Performance ColdFusion" but decided to give up my seat when I saw it was sold out (hopefully someone else will get in now!). There's a lot of excellent ColdFusion sessions at MAX this year but my focus right now is on Flex, AIR and real-time collaboration so that has driven most of my session choices.

Also a reminder that BACFUG meets on the Wednesday evening immediately after MAX ends and I am pleased to announce that we are having a double session with some MAX speakers:

• Bill Shelton and Marc Esher will present on Unit Testing in ColdFusion with MXUnit
• Joe Rinehart will present on Model-Glue 3: Gesture

We hope to have a good turn out with MAX attendees taking advantage of this (free) user group meeting in the evening! Since the meeting is inside the Adobe building, you will need to RSVP for security purposes. See you there!

May has been a quiet month on the blog because it has been an extremely busy month at Broadchoice. We completed our 2.0.2 and 2.0.3 releases and launched the new platform with a fair bit of press coverage.

The platform is powered by ColdFusion 8.0.1, running Model-Glue 2 (BER), ColdSpring 1.2 BER and Transfer 1.0 BER and runs on a cluster of 64-bit Linux servers with synchronization of the Transfer cache managed through a set of ActiveMQ JMS server instances. The database is MySQL.

We're continuing to work on a stream of minor releases as well as planning our next major release with a lot of new features.

I'll be pulling together some presentations and articles about how we're using the frameworks together (because I think we're doing some interesting and unusual things, behind the scenes). I'll some a few snippets of code at Scotch in both of my presentations (and again at CFUNITED). I'm talking to the CFDevcon organizers about appropriate topics and they suggested a framework-related session so that might be the first unveiling of some of our ColdSpring / Transfer tricks and tips. I expect Ray will also be blogging about some aspects of our application architecture in due course.

Feel free to sign up for a free Broadchoice account and see what we've been up to! Our support site (also powered by the Broadchoice Web Platform, as is our public website - we like to eat our own dog food!) has several ways for you to provide feedback to us!

Kay Smoljak is running a series of interviews with framework developers and has a summary article on SitePoint that includes a survey of people's framework usage. It's going to be a great series of articles and makes interesting reading (FarCry and COOP have been covered so far with Fusebox, Mach-II, Transfer and ColdBox coming soon - and Model-Glue and ColdSpring et al to follow). The survey will only be open for a few more days so rush over and make your voice heard!

That's a question that crops up over and over again. I've blogged about it in the past. My answer - as I'm sure most folks would expect - is "it depends". The question came up on a mailing list again the other day and someone jumped in full of praise for ColdBox and then someone else said "Sean would say it depends" and went on to plug cf.Objective() as the "perfect place" to answer the question, wishing they could be there.

Here's what I said in response:

[More]

This year's cf.Objective() has a lot of firsts. If you're not attending, you're going to miss out on a lot of world premier events!

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!

How can you pass this up? $629 for three full days of brain-cramming, enterprise-level information in a hotel that's only $120 a night! Register Now! The room rate is only guaranteed for a few more days!

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

Joe Rinehart just let me know today that his Model-Glue session will no longer be about Model-Glue 2 (Unity) but will instead be the first full public showing of Model-Glue 3, codenamed "Gesture". The session will cover the history and philosophy of Model-Glue and show how the new release "will make it easier then ever to employ architectural concepts like MVC and Implicit Invocation in your ColdFusion applications".

With all the buzz around AJAX - especially with CF8 making it so easy - we're starting to see a lot of questions about how best to integrate AJAX with MVC frameworks like Fusebox, Mach II and Model-Glue.

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.

Joe persuaded the folks who've contributed to Model-Glue to create Simpsons lookalikes so he could post this team photo. Enjoy!

After the networking event, Joe Rinehart hosted a Birds of a Feather session on frameworks. He covered the new release of Model-Glue 2.0 for ColdFusion, the Alpha 1 release of Model-Glue for Flex (which looks very exciting!) and said that Model-Glue for Java, developed by Chris Scott (I think) would also become an official Model-Glue project - all on the new Model-Glue website.

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...

Model-Glue just launched a brand new website (can you spot a theme here?), along with an Alpha download of the new Model-Glue: Flex framework.

I'll be blogging more about Model-Glue: Flex in due course - I'll be using MG:F, rather than Cairngorm, for the Flex (and AIR) development work I'll be doing over the coming months.

It's also worth noting that Model-Glue 2.0 is now an official release.

Joe Rinehart is hosting a birds of a feather session about frameworks on Wednesday night at CFUNITED. I'll be there, talking about the upcoming Fusebox 5.5 release. Joe will be showing off Model-Glue: Flex. Come and join framework authors - and frameworks enthusiasts - and share experiences and learn!

Update: this proxy is not needed to have a single instance of the Transfer factory shared between multiple Model-Glue applications. You can simply have an alias tag in each application that references the single transferFactory object in the parent factory: So why did I think this wouldn't work?

I created a test case for parent / child bean factories and aliases, I put nothing but aliases in the child factories. ColdSpring couldn't find the aliases. I deduced (wrongly) that ColdSpring did not allow aliases in child factories to redefine beans in the parent factory.

Silly me. Turns out that my test case uncovered a bug in ColdSpring: aliases only work if the factory contains at least one real bean. At least, that's what my test cases seem to show. I'm going to run this past the ColdSpring crew for confirmation.

---

Want to share a single instance of Transfer between multiple Model-Glue applications?

Original code / post edited out.

The definition of transferFactory is in your parent bean factory which you tell Model-Glue about by putting this line in your index.cfm:

(assuming your overall Application.cfc is creating application.cs).

All the Model-Glue apps share that Application.cfc and so they all have the same parent bean factory which contains the single instance of the Transfer factory object. Each Model-Glue app has its own proxy object that delegates an alias that refers to the single factory object.

The very latest Model-Glue: Unity (the SVN trunk) now has direct support for Transfer built in.

Joe mentioned that he has moved the explicit Reactor ORM support declarations out of the core Configuration.xml file. In that post he said you could just declare the ormAdapter and ormService beans directly yourself.

His code base has moved on (already). If you download the very latest from SVN and you have the very latest ColdSpring from CVS, then you can take advantage of the new <alias> tag in ColdSpring!

In your Model-Glue application's ColdSpring.xml file, just add these two lines to use Transfer:

Or, to use Reactor, add these lines instead: MG:U has built-in adapters for both Reactor and Transfer now and default declarations for both ORM's factories (as the ormService.* beans above). Of course, you can easily override any of these if you need (for example, we have the Transfer factory in our parent bean factory and define our ormService to be a proxy to the Transfer factory so that all our MG:U applications share a single factory object).

Joe has posted a fairly detailed explanation of the changes coming in Beta 2. One of the important changes for corporates looking at Model-Glue is the switch from LGPL to ASL licensing, bringing it in line with Fusebox (5.1 uses ASL2, previously Fusebox used a modified ASL1) and ColdSpring. For comparison, Reactor uses LGPL and Transfer uses CPL (Common Public License - similar to ASL in some ways and more acceptable to corporates than LGPL).

Another important change, particularly from my point of view, is full support for Transfer in the scaffolding, including parent/child relationships.

See Joe's blog for full details. Beta 2 should be available soon.

After Peter Bell stirred the pot, Peter Farrel wrote a fairly explosive post (repeating a lot of what he said on the cfweekly, episode ?) and it spurred Joe Rinehart to respond with an impassioned blog post defending the design choices made in the development of Model-Glue: Unity.

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).

I'm very excited to discover that Nando has finally decided to start blogging! Nando has been a regular contributor to a number of mailing lists that I'm on and I think we'll see some very insightful information on the blog. Already Nando has posted some great stuff about autowiring and validation (in Model-Glue: Unity).

Now that Mark has added a configuration object to Transfer, it's time to document how you can configure Model-Glue to use Transfer for the ORM integration which drives GDMs (Generic Data Messages) and scaffolding. First off, you need the very latest version of Transfer from CVS (see the transfer.riaforge.org website for details). Second, you need a fairly up-to-date version of Model-Glue (from SVN).

Third, crack open Model-Glue and edit one of the core files - shock! horror! Edit ModelGlue/unity/config/Configuration.xml and change the definitions for ormAdapter and ormService as follows:

The transferConfiguration bean definition will appear either in your Model-Glue's local ColdSpring.xml or a global configuration that is used as the parent bean factory for Model-Glue (see earlier blog posts about this sort of configuration).

Your Transfer configuration might look like this:

That's all there is to it! Model-Glue will now use Transfer for scaffolding and GDMs. Bear in mind this is an early cut of the integration right now. In particular, it doesn't support validation or any form of relationship yet. However, it should be enough to let you do basic table-based operations using Transfer.

Joe and Mark and I are still looking at what it will take to support relationships with Transfer in Model-Glue. To be clear, Transfer has sophisticated support for relationships but Model-Glue's ORM support is very Reactor-centric right now which makes this level of integration somewhat more difficult!

My lack of blogging lately is because I've had my head down coding, along with my colleagues Matias and Paul. This week we had several important milestones on our current project so we have been putting the finishing touching to some of our web services (Matias), build system (Paul - learning to love ant) and administrative consoles (me).

I've talked before about the structure of our service-based system: we use ColdSpring to manage all of the model components; we have simple web service / Flash Remoting facades in front of that model; we share that configuration with our Model-Glue applications using the parent bean factory feature of ColdSpring. I've been focusing on the Model-Glue side of the things this week, so I thought I'd blog about how that's working out for us.

[More]

Mark Mandel just made me a committer on the Transfer project so I added the first cut of the Model-Glue adapter (and metadata and dictionary objects) to CVS (on transfer.riasforge.org). No documentation yet - we need a separate Transfer configuration object (yeah, like Reactor has) before it becomes easy enough to use to be worth documenting. And I've realized that there are a couple of small enhancements to ColdSpring that will make it easier to swap pluggable adapters inside Model-Glue (already raised on the coldspring-dev list).

As folks can probably guess from recent posts, I've been taking another look at Mark Mandel's Transfer ORM library over the last few weeks and this weekend I've been looking at what it would take to integrate Transfer with Model-Glue.

Model-Glue has an adapter-based architecture for ORM and ships with an implementation for Reactor. It has an ORM controller that implements the "Generic Data Messages" (e.g., ModelGlue.genericList) and relies on a Reactor-specific adapter for the actual integration with the ORM.

The ReactorORMController that ships with Model-Glue is almost entirely generic because of the adapter interface which is a testament to Joe's great design skills. Because of that, I was able to get a basic Transfer adapter up and running fairly quickly to the point that the GDMs all worked. A bit more work and I was able to get basic scaffolding working too (by creating some basic metadata and a fake dictionary object).

I haven't tackled any of the table-to-table relationship stuff but I wanted to let a broader audience know about this proof of concept to gauge interest...

My team is building a lot of web services right now. Although we have a number of discreet groups of services, they share some common infrastructure and they all interact with a common database schema. We decided early on that we would use ColdSpring to manage the model components behind our web services and, as we've been building out the code base, we've settled on what seems to be a nice structure that allows each group of services to be developed fairly independently but still all be wired together as part of one ColdFusion application (so we can share data cached in application scope, for example).

[More]

You can now register for MAX 2006. The sessions & tracks are all listed as well. Plenty of ColdFusion sessions this year with a good range of levels. I'll be there as part of a three hour session covering frameworks and methodologies - ColdSpring, Fusebox, Mach II, Model-Glue and Reactor will all be covered. Yes, Fusebox at MAX!

Well, I guess this example just doesn't work too well. Part of the problem is my original app allowed you to add/update a task and add a new note on the same page which doesn't really fit with the default Reactor/Unity approach. The other part is that I relied on UUIDs for keys and right now I can't figure out how to make this work with Reactor/Unity with my legacy schema.

So I've taken the example offline until I've figured out a simpler solution. I'll probably build a new schema that uses auto-incremenet PKs instead since I know that works with Reactor/Unity!

I blogged about this a while back as an example of the power of custom lexicons. Over the last 24 hours, I completed enough of the Model-Glue custom lexicon to allow my original Model-Glue sample application to run as a Fusebox 5 application. You can download ggcc7fb5.zip and have a look - and if you have Fusebox 5 Beta 2, you'll be able to run it.

[More]

Well, Joe wowed everyone with his Breeze presentation today on Model-Glue: Unity. Brian Rinaldi has already posted a great summary of the presentation so I won't reiterate that.

Joe previously presented a fairly different version of the presentation to the Portland CFUG (which I haven't watched yet - Joe himself told me there was only about 10% overlap between the two talks). I kept meaning to watch that and write it up but it may be a little superfluous now.

I downloaded Model-Glue: Unity last night and have been experimenting with it, building a version of my cat show task manager application which I'll eventually bundle into frameworks presentation code. I don't have ggcc10 working yet which was supposed to show Model-Glue 1.0 / ColdSpring / Reactor but I will fix that and add it along with the new Model-Glue 2.0 (Unity) version, ggcc11, so folks will have plenty to compare.

My initial reactions? Wow, it makes prototyping applications incredibly rapid and it's easy to take the generated scaffolding code and modify it.

Joe has just announced the public availability of the first beta of Model-Glue: Unity.

His blog entry also provides links to thorough online documentation and a bug tracking system.

Why should you care about Model-Glue 2.0 a.k.a. Unity? Joe gives you ten good reasons on his blog. I'll give you another reason to care: all this 2.0 goodness comes in a backward-compatible package that will run all of your 1.x applications without changes meaning that you don't need to relearn everything!

Don't forget that Joe is presenting Model-Glue as part of Adobe's Developer Week series of free online seminars. You can register for this session as well as others that are scheduled for this week.

Wow! I've been following the development of Model-Glue 2.0 a.k.a. Unity pretty closely but even that hadn't prepared me for just how impressive Joe's video demo would be! In about eight and a half minutes, he builds a blog application (including manually creating the post / comment tables in the database).

From the video, you'll see that Unity uses Reactor to drive the database access and ColdSpring to manage both the Model-Glue service components and the Reactor factory itself. A very powerful combination!

Joe Rinehart talks about a very cool new feature in Model-Glue 2.0 a.k.a. Unity that allows you to write Model-Glue application "fragments" and simply drop them into existing applications through the use of a new <include> tag in the XML file. That's something Fusebox developers have been used to for a while (through circuits) so it's really nice to see a similar feature in Model-Glue! Go Joe!

I meant to blog this earlier but I was originally planning to hold out until I'd also watched Joe Rinehart's presentation to PDXCFUG and then compare the two. Time passes so I figured it would be better to go ahead and blog about Ray Camden's Breeze presentation on Model-Glue. You can also download the presentation as PDF and download the example code from that Nashville CFUG web page.

Ray did a great job of introducing Model-Glue, coming at this from his own experience of learning the framework and how it's helped him organize his code. Ray starts out with just a few slides to define some terms and then switches to screen sharing, showing how to build a real Model-Glue application (press release listings) from scratch with a focus on the framework itself. He makes a very clear distinction between the application model (which should be framework-independent) and the controller (which is tied to Model-Glue).

It's a great introductory piece for anyone just coming to Model-Glue or still considering which framework to use.

I'll post about Joe's presentation later, when I finally find the time to watch it all the way through.

Just saw this mentioned on my colleague Ben Watson's blog: Adobe Developer Week - June 12-16 - a series of online seminars covering a broad range of Adobe technologies and including quite a few Flex and LiveCycle sessions, but also Ben Forta talking about building ColdFusion-powered Flex applications and Joe Rinehart talking about ColdFusion and Model-Glue! It's all free - you can sign up for just those sessions you are interested in and you can attend from your own desk (or home)!

The members of my team, Hosted Services, has a wide variety of backgrounds and experience but, until I joined the team, had not looked at ColdFusion as a viable technology for doing integration work.

The benefits of ColdFusion are slowing becoming apparent to my (formerly non-ColdFusion) colleagues: Java integration is fairly seamless, exposing code through web services or Flash Remoting is almost trivial, high-level tags that simplify integration tasks.

Within my overall team, I run a small group focused on core infrastructure and integration and we're getting into some prototyping work now and for that we're going to use Model-Glue to build quick HTML user interfaces and test harnesses and Reactor to simplify the data access layer, with a view to moving to custom SQL queries for performance later on. Given the ease of using ColdSpring with Model-Glue to manage the service layer, I strongly suspect we'll end up using all three frameworks together for our prototyping.

Over time we'll build out Flex 2 user interfaces, probably even for the internal administrative consoles that we might initially build using Model-Glue. The service layer we build should be directly reusable in that situation.

So far, the initial response to Model-Glue, ColdSpring and Reactor has been positive and we're looking forward to Model-Glue 2.0 a.k.a. "Unity".

Joe has posted some information about Model-Glue, saying there will be a final 1.1.1 release with some performance tweaks and that Model-Glue 2.0 is just about ready to go "Alpha 2". I've been talking to Joe about Model-Glue 2.0 and I'm already very excited about it - I think it has huge potential and will be a massive productivity tool for ColdFusion developers!

This weekend I had a little chore, courtesy of my wife and her cat fancy involvement: a simple web application to manage some remote files on the regional website (for which I am webmaster). The website is hosted on GoDaddy so quite a few tags are disabled. What my wife needed was a way to upload and manage files on that website, in a way that let her control what information was shown on the website's finances page (she's treasurer).

I wrote a small Model-Glue / ColdSpring application that runs on her machine (which already runs the IRC bot) and lets her push files from the local financial folder tree to a specific directory on the remote website.

I figured it might be useful to someone so you can download the code from my software pod (right hand side of my blog).

Here's the code embedded in the web page on the regional website:

The files.cfm file is created and managed by the File Manager app as a way to control what is shown on the website.

To configure the app, edit filemanager/config/beans/beans.xml and change the local home directory and the remote server configuration.

The UI is very basic (hey, I'm an engineer not an artist!) and is modeled after the "webpush" utility Macromedia used to manage content on macromedia.com (with color-coding to indicate files that are the newer locally, the same, missing locally and missing remotely).

Anyway, if you find it useful, have fun with it. If nothing else, it's another example of using Model-Glue and ColdSpring together.

Someone asked on the Model-Glue mailing list how to keep deal with keeping event handler names and URLs in views consistent, i.e., if they change an event handler name, how can they avoid having to change the string wherever it appears in links in their views.

Fusebox has long had a convention to deal with this known as XFAs - eXit FuseActions. The idea is to abstract the actual fuseaction name into a variable. You specify all the exit points for a view as XFAs in the XML and refer to the variable in the view instead of hard-coding the fuseaction name. If you need to change the control flow - or the fuseaction name - you just change the XFA in the XML file and your views all pick that up. Often Fuseboxers set common XFA values in the prefuseaction for the circuit or the global preprocess fuseaction for the application, making it very simple to manage exit points.

You can do something similar in Model-Glue by using the value tag on an include:

Your view can refer to the exit point as a variable when building the URL like this: Note that Model-Glue creates the myself event value automatically from the defaultTemplate and eventValue settings in the <config> section of your ModelGlue.xml file. This abstracts even the file name and event key out of your views and is good practice. Again, something borrowed from Fusebox conventions (although Fusebox does not do this automatically - it's just a common convention).

If you want to set exit points globally in Model-Glue, you could make them settings in the <config> section and then have a listener for onQueueComplete which pulled all xe.* settings and added them to the event (view state).

Jared Rypka-Hauer is maintaining up-to-date versions of the CFC Documentation of these frameworks for the community.

I leave this example to speak for itself...

fusebox.xml:

circuit.xml:

Controller.cfc:

views/main.cfm:

This is using what will be the Alpha 2 codebase...

Updated to add some clarification on my views about performance!

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

And I should have pointed out that none of the versions were optimized for speed. However, I'll bet that if they are all optimized, the results overall won't be too different - at least, not different enough to make any overall judgments and, in particular, framework choices based on.

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

---

Those wonderful folks over at Webapper have been doing some load testing on various frameworks using the ColdFusion PetMarket application (featured in the February CFDJ). They tested Fusebox 4.1, Mach II and Simon Horwith's "no framework" versions of PetMarket. Fusebox 4.1 was the fastest which really isn't much of a surprise since it compiles everything down to straight line CFML on the first request so subsequent requests just process a single file. What surprised me was that the Mach II version outperformed Simon's version (albeit, not by very much). Overall, Simon's version was 100% slower than the Fusebox 4.1 version. Unfortunately, Webapper couldn't test the Model-Glue version because "the PetMarket Model Glue application was not fully functional". Based on my experiences, I'd expect Model-Glue to fall somewhere between Fusebox 4.1 and Mach II performance so I hope they get a chance at some point to show that.

Joe Rinehart just announced the release of Model-Glue 1.1 and talked about the forthcoming Model-Glue 2.0 aka "Unity". He also said this is the end of 1.x development. Joe has said that 2.0 should be backward compatible with 1.x (I expect some applications may need a few small tweaks to run on 2.0 - backward compatibility is hard) so this should not cause any panic for existing Model-Glue 1.0 users. In fact, if you're using 1.0, you should feel comfortable downloading 1.1 since it fixes a few bugs and introduces official ColdSpring support.

Joe quotes around 10,000 downloads for Model-Glue which is phenomenal! Congratulations Joe!

I'm looking forward to Model-Glue 2.0, even as I work on Fusebox 5. Both new releases will provide a cleaner, more maintainable, more powerful set of core files while retaining substantial backward compatibility with the previous releases. This should be seen as a testament to the stability and maturity of those previous releases. In some ways, Fusebox 4.0 was really a "1.0" release since it a new way to write Fusebox applications, using XML and Fusebox 4.1 was therefore "1.1" - and Fusebox 5 will be "2.0". Model-Glue and Fusebox are moving forward: a brand new set of CFC-based core files that bring more expressive power, while building on the shoulders of the "1.x" applications that are out there.

It's a good time for frameworks users!

As an example of how to hook these together, here are two bean definitions (from the ColdSpring XML config file) that show how to have ColdSpring create and inject a Reactor gateway into your Model-Glue controllers: Kurt Wiersma recently updated ColdSpring so you can define a factory and specify that other beans are obtained from that factory instead of directly from ColdSpring.

In the ModelGlue.xml file, specify the ColdSpring loader and that you want autowiring:

Finally the controller has a setter for the task gateway: ColdSpring will create the Reactor factory bean and then use it to create the task gateway and will then inject it into the controller for you.

Magic!

Model-Glue, ColdSpring and Reactor have all been updated in their repositories to handle the issues that I have talked about over the last couple of days. I'll be packaging up "ggcc10" for release at / after cf.Objective() - the Model-Glue / ColdSpring / Reactor variant of my frameworks comparison sample application.

Reactor is also getting some performance tweaks - some are already in the repository, more will be committed before cf.Objective() (do you see a pattern here?).

Check out the latest "BER" versions to try out the new abilities!

As part of the preparation for my talks at cf.Objective() (it's not too late to buy your ticket!), I've been working quite a bit more recently with both ColdSpring (for my factories talk) and Reactor (for my persistence talk).

ColdSpring has recently been enhanced to support factory-bean and factory-method attributes in a bean definition so that you can declare beans that are actually created by external factories such as Reactor.

You declare the Reactor factory as a bean (managed by ColdSpring). Then you can declare DAO and gateway objects, in the ColdSpring XML file, which are created by the Reactory factory bean.

It's very slick.

However, most Reactor operations are focused on record objects which are transient (not singletons) and whilst those could be managed by ColdSpring, generally only singletons - per-application objects like services - should be managed by ColdSpring (since it adds a layer of complexity to object creation in order to leverage the power of the framework).

I was attempting to apply AOP to Reactor-generated objects so that I could simulate the security model in ggcc9 (the ninth variant of my frameworks comparison code - see the software pod on my blog). ColdSpring assumes that AOP-controlled objects are simple concrete classes and therefore it doesn't work with the nested inheritance hierarchy of the Reactor-generated DAO and gateway objects.

I did eventually make it work but it requires changes to ColdSpring and, for some of the autowiring I was doing, some changes to Model-Glue as well. I've submitted the patches to the revelant mailing lists for consideration but it means that I can't realistically release the ggcc10 variant's source code.

Despite my minor frustrations, the combination of the three frameworks is immensely powerful. If you look at the ggcc9 variant, you'll see it has several model CFCs and several bean CFCs. The ggcc10 variant has none of that. The model was really just DAOs and gateways which Reactor provides automatically and the beans become records which, again, Reactor manages automatically. About a dozen CFCs went away in the conversion. That's a lot of code I wouldn't have to write!

I made a minor update to my frameworks sample code. Jared pointed out that ggcc9 - the Model-Glue / ColdSpring variant - was still using my old "autowire" controller. I updated the example to use the built-in ColdSpring autowiring in Model-Glue.

I added the following setting to ModelGlue.xml:

and removed the declaration of the "csaw" controller.

At some point I'll update this variant with the feedback I had from Chris Scott and/or Dave Ross who suggested (correctly) that the aspect should call the model and the actual check identity code should be there instead.

Eddie Awad has pulled together a nice, short FAQ about Model-Glue that covers a lot of the common "how to" questions that folks new to the framework tend to ask. Good work Eddie!

Joe has posted a teaser for a template application for Model-Glue 1.1. This looks like a pretty complete skeleton app that shows how to do authentication and authorization, database access and so on - a "recipe book" for Model-Glue applications! Sweet.

Joe Rinehart has announced that Model-Glue 1.1 is near! The new release will bring tighter ColdSpring integration, an all-new "starter kit" application template, redirects on unnamed results and result mappings for onRequestStart.

He also announced that Chris Scott has created an alpha pre-release of Model-Glue for Java.

Doug Hughes has finally caved to public pressure and made available his .NET port of the Model-Glue framework. His blog entry offers plenty of caveats so take due notice before you download it (and remember folks - don't bug him about upgrading it to Model-Glue 1.0... he's got other things to do so feel free to upgrade it yourself!).

As he says, if you end up using it, comment on his blog entry to let him know!

I've been playing with Arf! quite a bit lately and I thought I'd share some of the code in my little sample app, just to show how useful Arf! can be for small dynamic applications.

Naturally it's cat-related. I built the On Safari website last year (I am not responsible for the visual design!) using Fusebox and what little dynamic content I needed I was loading into the database from CSV files.

This year I decided to build a small content admin section to make this a more pleasant process as I add more content that people send me about past On Safari shows. For the admin, I decided to use Model-Glue, ColdSpring and Arf!

Code to fetch all the awards and sort them by year and sequence number:

Code to read in a single award record by ID:

I treat the record as a bean later on in the code so I actually reuse this method for both the 'add' and 'edit' scenarios. If the awardId is blank, then I get an empty 'bean' to populate the form - otherwise I get real data (my add and edit forms are the same view).

Code to save an award (either new or edited - Arf! knows that a blank ID means add a new record):

And, finally, code to delete an award:

You can decide for yourself how much work this saves. The cataward CFC is essentially empty (just the Arf! template). It was certainly nice not having to write CRUD SQL but in an app this size there wouldn't be very much of it.

It works, it's reasonably fast - certainly fast enough for my little admin needs.

What could I do better? Well, I ought to have a separate DAO layer and isolate the use of Arf! inside that rather than just manipulating Arf! in my controller but I just wanted a quick'n'dirty content admin. I'm only using ColdSpring to create and load the Arf! Datasource and RecordFactory objects (overkill but convenient). I'm using the autowire feature (in the ColdSpring CVS version, not yet released).

Chris Scott (ColdSpring AOP) recounts his experience of learning Model-Glue in a day as he converted his ColdSpring AOP sample application from Mach II to Model-Glue. Interesting to hear a framework author's views on other frameworks.

I mentioned this feature earlier as an add-on but wanted to let folks know that the next release of ColdSpring will include the Model-Glue autowiring code (Dave Ross gave me commit access to the CVS repository - thanx!).

That means that the Model-Glue / ColdSpring integration will be as simple as:

Specify the ColdSpring bean factory loader and location of the ColdSpring bean definition file in ModelGlue.xml:

Adding the autorwiring controller (as the first controller): Adding setXxx(yyy) methods to your controllers, where xxx is the name of the ColdSpring bean you want to be injected automatically.

If you've already downloaded my frameworks sample app you'll have seven variants of a single application, all using different frameworks in different ways. Tomoaki Tanaka created an eighth variant, blending Model-Glue and Tartan (mentioned previously on this blog - thank you!). I have now created a ninth variant using the tiered OO model of variant #5 (a Mach II variant), the Model-Glue framework and the ColdSpring framework.

In order to try it out you will need the BER of Model-Glue (which has Joe's latest ColdSpring integration), the 0.2.1 release of ColdSpring which includes both AOP and the Model-Glue adapter from Dave Ross, and you will also need this extension to ColdSpring that adds auto-wiring for Model-Glue controllers.

In this variant, ColdSpring manages all of the model (except the transient note, task and user beans - I may convert these later) and it also autowires the various beans into the controller objects at startup (so the controller objects have no internal initialization code!).

I've also modified how security is managed to use ColdSpring AOP. In the previous Model-Glue variant (#7), security was checked explicitly in various event handlers by broadcasting the checkIdentity message. Now it is handled through "before advice" on the taskDAO and taskGateway objects, using ColdSpring AOP. The advice performs the security check and throws an exception if the user is not logged in. In the exception event handler, a message is broadcast that causes event results to be set if the exception can be handled by another event (in this case the security exception can be handled by the ggcc.identify event, which challenges the user to login).

I think this shows the power of these two frameworks in combination!

ColdSpring can deal with the drudgery of creating and initializing all of your model CFCs. Very nice. But when you're using a framework, you still need to explicitly 'wire' the model to the controller - by calling ColdSpring's bean factory to obtain the bean and storing it locally inside your controller. No big deal, you might think, but if ColdSpring can build all of your model for you, why can't it wire it into your controller as well?

The simple answer is because it doesn't know about your application framework so it doesn't know about controllers.

Dave Ross and Chris Scott are working on a plugin for Mach II that will allow ColdSpring to automatically locate the listeners, plugins and filters in your "controller" and look for setXxx(yyy) methods in them. If it can match a setter to a bean that it knows about (from the ColdSpring bean XML file), it will automatically invoke the setter for you.

I thought that was a great idea but I wanted it for Model-Glue!

So I wrote an AutoWire.cfc for Model-Glue. It relies on Joe's BER changes to Model-Glue to support the ColdSpring bean loader. I've submitted it to Joe, Dave and Chris so hopefully it will be incorporated at some point.

---

How it works: Model-Glue creates the bean factory, then creates the controllers. With the ColdSpring changes that Joe listed, Model-Glue creates the ColdSpring bean factory instead of its own (ChiliBeans). My AutoWire.cfc is a controller that you declare in the XML (as the first controller). At startup, when Model-Glue creates that it, AutoWire then modifies the in-memory Model-Glue object so it can intercept subsequent controller creation. Then, as Model-Glue creates the remaining controllers, AutoWire searches for setXxx(yyy) methods on each one and attempts to match them to beans declared in the ColdSpring XML file.

If anyone is desperate to try this out, I'm happy to send you the work-in-progress code...

After my previous post about integrating ColdSpring, Model-Glue and AOP, Joe went ahead and incorporated a hook for ColdSpring directly into Model-Glue. It works beautifully!

I was able to remove the ColdSpring bean factory 'hack' from my controller (see link to Dave Ross's post in my previous entry) and just make the ModelGlue.xml changes that Joe mentions. Using ColdSpring is now so easy with Model-Glue that I expect this is how I'll be building applications moving forward!

After a little bit of trial and error, I just succeeded in (a) integrating ColdSpring with Model-Glue, (b) defining logging advice after a method call and (c) actual logging results returned from methods!

Dave Ross shows how to use the Model-Glue adapter in ColdSpring - the returnType= attribute should actually specify the fully-qualified return type tho'. That combined with Chris Scott's AOP tutorial and a quick read of the source code (download from coldspringframework ).

My LoggingAfter CFC extends coldspring.aop.AfterReturningAdvice, implements afterReturning() which logs a message and then returns arguments.returnVal (very important!).

My ColdSpring XML file specifies:

• xxxTarget - my actual bean that I want to log methods in
• xxx - a coldspring.aop.framework.ProxyFactoryBean that references xxxTarget and uses the logAfterAdvisor intercepter (below)
• logAfterAdvice - my simple logging class
• logAfterAdvisor - a coldspring.aop.support.NamedMethodPointcutAdvisor that specifies my logAfterAdvice as the advice property and * as the mappedNames (matches anything)

The results of calling methods in xxxTarget are logged automatically!

Logging can be disabled by renaming the xxx and xxxTarget beans (so that my application code calls the actual bean, via the name xxx, instead of the proxy).

Very slick...

---

Update: see the next blog entry for an even simpler integration!

Just a reminder that there's a set of fairly active (if often off-topic) chat channels established on DAL.net IRC for ColdFusion developers. The main channel is #coldfusion which has a bunch of irreverent and fun regulars and then there are channels registered for several of the application frameworks: #fusebox, #machii, #modelglue, #tartan. In anticipation of ColdSpring becoming increasingly more popular, I have just created and registered a #coldspring channel.

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.

Andy Jarrett is getting onboard with Model-Glue and has posted a number of useful resources.

Joe Rinehart has officially released the much anticipated 1.0 version of Model-Glue. Lots of great enhancements in this release - read his blog for details!

Things I like: built-in redirects with event state management, event beans, ability to plugin SES directly into the framework, simplified configuration - lots of defaults now! And of course the ability to declare asynchronous messages (relies on my Concurrency library).

I'll be in Portland this Thursday, speaking at the Portland ColdFusion User Group about application frameworks. I've given versions of this talk at several conferences and user groups over the last year but I've updated it this time to include Model-Glue on a par with Fusebox and Mach II.

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

Looks like I'll be taking my recently updated application frameworks talk to the Salt Lake ColdFusion User Group at the end of September (for their 'October' meeting) since I'll be in town for a cat show that weekend (the last weekend of my sabbatical). Kudos to Matthew Reinbold for twisting my arm and making it possible!

The early bird price of $299 ends TODAY then it goes up to $499 so hurry along and register for the 2005 Fusebox & Frameworks Conference!

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)

Those classes are just $449 each!

The Fusebox & Frameworks conference is coming together nicely - take a look at the list of topics and speakers! All the major frameworks are going to be covered: Fusebox, Mach II, Model-Glue, Tartan, onTap, Rails, Spring and various custom concoctions! I think it's particularly interesting to see Rails and Spring on the menu (with talks from John Paul Ashenfelter and Maxim Porges respectively).

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!

John Beynon, author of the great Learn Fusebox tutorials, is busy converting a Mach II sample application over to Model-Glue as a way to both learn the Model-Glue framework and come to terms with OO. He's going to post the result as an example for others making the transition and/or learning the Model-Glue framework.

Joe talks about what's coming in Model-Glue 1.0 and asks for your feedback on the new features.

Ray Camden asked on the Model-Glue list about whether there was a way to avoid repeatedly typing the application name in the XML configuration file. Wayne Graham came back with a brilliant way to do this that uses XML entities - definitions of &entities; directly in your XML file.

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.

Michael Smith has just announced the 6th Annual Fusebox / Frameworks Conference at the end of September. The call for speakers / topics is open now until July 25th. This year's conference will cover more than just Fusebox and FLiP - it will cover a variety of frameworks based on the topics you request!

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!

An interesting commentary from Adam Crump about how hard these frameworks are to learn. I won't add any additional commentary here because I already posted a comment on Adam's blog (and I think Adam already covers all the bases in his post).

I'd like to thank Tomoaki Tanaka for taking my frameworks sample application and creating a Model-Glue + Tartan variant. I downloaded his ggcc8.zip file, unpacked it into my web root and it worked just fine (although I'd recommend setting reload to false in ModelGlue.xml so you get good performance.

This appeared over the weekend and, as its name suggests, answers many commonly asked questions about how to do things with Model-Glue!

Jared has posted a really good tutorial on structuring event handlers in Model-Glue, showing how to handle security / validation and layout in a clean chain of event handlers, leveraging the <results> tag.

I just heard that a new Birds of a Feather session has been added to the CFUNITED schedule. Wednesday, 9pm. I look forward to meeting other Model-Glue users - and folks who are interested in learning more about Model-Glue!

---

Update: It'll be a panel from 9:00-9:30 followed by a Breeze presentation for AZCFUG, live from the BOF room!

Peter Farrell seems to think so in a couple of posts on his blog. He thinks the excitement over Model-Glue is killing Mach II. Pop over to his blog and let him know what you think!

After publishing the sample code, I decided to have another pass through my presentation. With the current surge in popularity of Model-Glue, the "Fusebox vs Mach II" nature of the talk feels a little dated to me (gee, how fast things change in IT!) so I decided to add copious notes saying where Model-Glue is similar / different to both Fusebox and Mach II. Naturally, it has more similarities with Mach II than with Fusebox but the "third leg" of comparison is enlightening all the same.

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?

Steven Erat has signed up for Joe Rinehart's refactoring to OO course on the Tuesday before CFUNITED. Like me, Steven is excited about this new(ish) framework. He has read the quickstart guide on the Model-Glue website and has both praise and criticism for it. He mentions Trond Ulseth's (excellent) Mach II documentation as a comparison - and Trond responds, commenting on the lack of Mach II documentation.

There seems to have been a sudden upsurge of interest in Model-Glue and, in particular, a DTD for the XML control file. Several people have offered DTD files but Joe is (quite rightly) saying he wants to hold off releasing a DTD until Model-Glue reaches 1.0 status. That'll be pretty soon at the rate things are going.

Anyway, I've been taking everyone's feedback on board and sent a draft 0.9 DTD to Joe today - we'll keep working on a solid DTD for the 1.0 release. In the meantime, I'm using my draft DTD to validate my Model-Glue XML files in the apps that we're building, to try to iron out any problems.

I mentioned that I tripped over a curiosity when converting my Mach II app to Model-Glue: there was no easy way to process a rendered view in Model-Glue.

I've looked at several workarounds and settled on something I don't feel uncomfortable with (you can tell that I still don't like it!).

To be honest, Mach II allowed me to mix presentation and business logic too easily by placing rendered views into the same "scope" as business data. Model-Glue fixes that by (a) running all the business logic first (in the broadcasts section) and (b) putting rendered views into a different space (viewCollection as opposed to viewState).

Thinking about it, what I really wanted to do was publish a rendered view to a different medium - email. I figured that my layout - which handles what happens to the rendered view data - would be a reasonable place to hook into. The layout view has access to the viewCollection which contains the rendered view state and to the viewState itself. If the viewState contains a hook into the model, you can do this without breaking encapsulation. Or at least without breaking it in any major way. Your call.

So, what I did was: in the the controller method that sets up the email parameters in the event object, I injected this as the "notifier" event value, thus making a callback possible. Then in my view, I check if viewState.exists("notifier") and if it does, I store viewCollection.getView("main") into the event object (as the "body" value) and then invoke viewState.getValue("notifier").sendNotification(), passing in the view state. The controller method (sendNotification()) does not take an event, like regular Model-Glue controllers, it takes a ModelGlue.Util.GenericCollection.

Is it still a hack? Probably. Is it a violation of MVC? Probably not. Can you come up with a cleaner solution?

For a "small" point release (from 0.85 to 0.90), there's a lot of meat in the 0.9 release of Model-Glue. I think Model-Glue is the first mainstream framework to include timed cache functionality. It's also the first framework to include a sophisticated debugging trace facility - 0.9 adds the ability to trace arbitrary data during execution.

Now that my application conversion is complete and tested, I want to talk about some of the issues I ran into and some of the differences in approach that I had to take between the two frameworks.

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:

instead of just: The event object is the data bus in Model-Glue and it becomes the view state (for rendering views). Contrast this with Mach II where the data bus is really the request scope but because listeners operate on the event object, you need to shuffle request scope data into the event object if it is needed inside a listener. You trade off a bit of inconvenience for a lot of consistency and better encapsulation.

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).

I bet that grabbed your attention?

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.

Joe Rinehart has posted a great tutorial on using configuration beans for applications, based on his ChiliBeans bean factory (part of the Model-Glue framework).

He says:

"By using ConfigBeans instead of inserting configuration values, like Datasource names, into your ModelGlue.xml file, you can seperate your configuration from your application."

Trond has posted a useful high-level summary of various application frameworks on his (beautifully designed) Waterswing blog.

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.

Since Joe is keeping the QuickStart guide up-to-date with every point release, it's probably a bit early to highlight features of Model-Glue that are not documented but I'm using this feature and I think it's very useful.

In addition to the onRequestStart and onRequestEnd messages that the framework automatically broadcasts (at the start and end of each request - duh!), it also broadcasts a third message that is not documented: onQueueComplete. That is broadcast after all of the events and messages have been processed and the views are all queued up for rendering. This is a very useful point at which to add view-specific state information.

Joe has made Model-Glue 0.8.50 available which incorporates the view-value idea that allows you to specify parameters to views that are effectively default view state values: In this example, the view state value xfa.home is always given the value "homePage" and the view state value xfa.admin is given the value "loginPage" if a controller has not already set a value for it.

I noticed that the (very useful) debug trace does not show what happens prior to an exception which would be very helpful in debugging what caused an exception. I figured out a small fix for that and sent it to Joe as a suggestion for a future release.

I'm going to spend some time adding Model-Glue into my framework comparison matrix (a spreadsheet) to see how it stacks up overall and I'll probably publish that on my blog in due course. The spreadsheet formed the basis for my Mach II / Fusebox comparison talk so it'll be interesting to have another framework represented.

The sample application which I'm using to illustrate my Fusebox and Mach II framework comparison talk now has a Model-Glue variant! That's seven variants altogether:

• Traditional Fusebox
• MVC Fusebox
• OO Fusebox
• Simple Mach II
• Refactored Mach II using design patterns
• Fusebox + Tartan
• Model-Glue

I'll be making the code available for download after the CFUNITED conference. I still need to add some readme files and maybe tidy up some of the code.

So what was it like building a Model-Glue application? Not bad once I got over a few "Mach II-isms" - mostly XML syntax problems caused by a lack of familiarity with Model-Glue. I did find one big hole in Model-Glue tho': there was no way to declaratively pass arguments to views, such as you typically do with Fusebox (XFAs - eXit FuseActions) and I've started doing with Mach II as well. I mentioned this to Joe and he seemed to think it was a good idea so I modified a couple of core files and sent the edits to him. Expect to see view arguments in a future release of the framework!

I do like the clean, consistent approach of controllers listening to messages and event handlers broadcasting messages and all communication done via the event object (which becomes the view state).

Where I would notify a listener in Mach II to get me some data (or invoke a component in Fusebox), I broadcast a message instead and name it "needXYZ" to indicate the view needs XYZ data. The relevant controller listens for needXYZ and usually calls getXYZ. It makes the XML read quite nicely. Thoughts?

Joe Rinehart has released Model-Glue 0.8.00 and Paul Kenney has released Tartan 1.0.3. Model-Glue gets public / private event handlers (yay!) and a bit of restructuring in terms of the samples and skeleton application (and a bug fix in result handling). Tartan gets bug fixes and better Mach II compatibility.

The Model-Glue application framework now has a mailing list on Topica for discussion of the framework. Joe has also released Model-Glue version 0.7.00 which includes exception handling, debugging, whitespace control and some tidying up of the code infrastructure.

Joe Rinehart has released his lightweight implicit invocation MVC framework, Model-Glue. I haven't had a chance to download and play with it yet but I will commend him for very quickly getting some great documentation up!