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.

ur web services are backed by a variety of fairly simple database tables and we're using both Reactor and Transfer to manage the persistence of data (with the respective factory objects injected into the model automatically by ColdSpring). All of the internal administrative consoles are powered by Model-Glue. We have LDAP-based security for these consoles and Model-Glue makes it very easy to create a self-contained "action pack" to perform security and then apply it to all of our Model-Glue applications.

An action pack is a mini-application that you can integrate into another Model-Glue application using the <include> directive inside your main Model.xml file. We have a LoginController, a login form (view) and two event handlers (showLogin and doLogin) defined in our security action pack. The LoginController listens for the onRequestStart message and checks if the user is authenticated. If yes, the <result> tag redirects to page.index other it redirects to showLogin. Nice and simple... write one security module and included it into all the apps. Thank you Joe!

For the most part, the administrative consoles are just simple CRUD form-based applications. As a first cut I simply used the <scaffold> tag which gave me a list page, a view page, an add/edit form and the ability to delete records. Mostly, I just copied'n'pasted the generated Scaffolds.xml files into the ModelGlue.xml files so I could tweak the event handlers (I added search functionality to a couple of the consoles and tweaked the ordering in some others). I also copied the generated views into the main views directory and tidied up the breadcrumb labels and added my own custom navigation to the standard layout template. All of my tables have datecreated / dateupdated columns which are set by triggers for audit purposes. I updated the scaffolded view page to format the dates properly and removed them from the list and add/edit pages. Thank you Joe!

The action pack concept and the scaffold functionality have made it possible to build out secure consoles for a dozen database tables in a matter of hours and have a reasonably nice looking, usable set of data management tools - all created between the endless meetings I seem to spend my days in!

A productive combination: ColdSpring, ModelGlue, Reactor/Transfer and, of course, cfcUnit to make sure changes don't break stuff.

I think ActionPacks are the real sleeper feature in MG:U. Scaffolding? It's ok. Reactor integration? Not so useful in my opinion (so far). ActionPacks? Now we're talking!

Mark

Our data tier is pretty simple so we weren't really taking advantage of Reactor's gateway machinery and nearly all of our load operations were using combined non-PK fields.

Transfer has built-in data caching and our services are very performance-sensitive so, along with the considerations above, Transfer turned out to be the better fit for us.

Building the Model-Glue adapter for Transfer was just a natural outgrowth of that - making it easier for us to leverage some of Model-Glue's RAD prototyping tools (GDMs and scaffolds).