I've floated a few .zips of Model-Glue:Flex around, and so far, so good. However, one person who's not currently doing much Flex development had what I feel will be a key piece of feedback: the early zip did a lot to implement implicit invocation and the friendliness of Model-Glue, but it did nothing to remove the boilerplate that often goes along with writing a Cairngorm application that uses a service layer.

The Problem

A lot of Flex developers, myself included, use Business Delegates to separate the implementation of server-side services from the rest of our application.

Big term, easy concept: the delegate just wraps all the functions of the service.

Then, when we want to call the server, a Command calls the method on the delegate, stating that the Command should be used as the responder.

This means that any time I'd like to work with a new server-side operation, I've got a few things that are going to either slow me down or mess me up:

1. I've got to add boilerplate to the delegate:

   public function doSomething():void {

   var token:AsyncToken = service.listDynamicStrings();

   token.addResponder(command);

   }

2. I've got to implement responder functions:

   public function result(data:Object):void { }

   public function fault(data:Object):void { }

3. If, for some reason (rare, but I've hit it), I need to make two server-side requests in one command, I've got to monkey about with responder delegates to get them to call different methods in the command.

While it's not *that* much code to write, when you stack it on top of creating the Command class (which is really not much but a procedural script), an Event class, and having to relate the two in the Controller, there's a lot of typing to be done.

So, my earlier reviewer basically said "Can you get rid of the yuck? Maybe you could write a dynamic proxy, handling methods not being found, that'd wrap a service and let you assign result/fault functions?"

Model-Glue:Flex's Solution

Ugly terms like AsynchronousMethodProxy aside, I've cooked up something that has a real feel of Model-Glue "easiness" to it - it's a little loosely typed, but darned easy to use.

The "autoproxy" lets you ask for any AbstractService (like a RemoteObject tag) in your ServiceLocator and make arbitrary method calls, using the name of the server-side function (e.g., <cffunction>). You just pass it whatever arguments the function requires, an optional result function, and then an optional fault functions. It's a lot like prototype's style of making Ajax calls.

Ok, code works better than words. This is all you have to do to ask for a list of contacts and use it as the source of an ArrayCollection in a model locator:

Let's spice it up and add a filter string as an argument and a reference to a common fault function:

Any takers, thoughts, flames?

I figured I'd better blog this while I had some downtime at the cf.objective conference. In my Model-Glue session today, I previewed an experimental AS3 Model-Glue implementation of Model-Glue, providing a lighter weight / looser / more implicit architectural framework in comparison to something like Cairngorm.

There's no docs, I've written one sample app, and I'm not sure this'll ever be an 'official' Model-Glue thing, but I'd like to ask if anyone would be interested in taking a look: leave a comment and I'll send out a zip when it's ready...I need to do an FDS example and a Quickstart.

The other day, I posted about adding Cairngorm event listeners directly into your views. Just summarizing it like that, it should already sound like a wonky alternative to using ViewHelper/ViewLocator (which, to me, is even wonkier).

Here's my situation:

I have a login form that I'd like to have to something "special" when login fails, like blink or turn red or play a very loud siren noise. Whatever that is, I can't get there by just binding to a "workflow" value in the ModelLocator: I need to call a function in the view.

Jay Proulx posted a possible solution that created a separate "ViewController" concept, where a class would extend Canvas and define string constants representing various states. It's a nice way to separate the listeners out of the views, but it still doesn't go where I need to be: having functions that play things like effect sequences in response to architectural events.

So, I combined his idea, mine, and the basic UI event system to create my own ViewController class.

Here it is (nothing special):

Nothing fancy. Extends UIComponent and adds an addListener() method that'll add a listener to the CairngormEventDispatcher.

However, I can then extend it with something like LoginViewController. LoginViewController adds a listener for the USER_LOGIN_RESULT_EVENT, and depending on the authentication status of the user involved, raises a plain old UI event:

Now I'm in business. Instead of dealing with views by an arbitrary ID (my main issue with ViewLocator/ViewHelper) or giving my view knowledge of the Controller view (my main issue with my earlier workaround), any view that wants to deal with login failures or login succeses can do this:

It's a bit like ViewHelper, but backwards enough where it works implicitly instead of explicitly.