1. Model is a global repository for data
2. Views use databinding to "watch" Model data changes and show formatted data.
   Views allow user interactions and dispatch user gestures as events
3. Controller forwards events to commands for processing
   Commands update model data
4. .... back to (1).

Consider the Cairngorm approach where a Command instance employs a Delegate class as "proxy" to the remote data services. The command instance "submits" itself as a responder to the delegate. The delegate, in turn, simply uses the specified responder [via the async token] to allow data service responses to go directly to event handlers within the command.

But how can the view be directly notified of the data service response and status? In the "real world" databinding solutions espoused by Adobe is not always sufficient...

However, the solution proposed in that blog requires several compensations:

1. Views must employ/register private view controllers with the front controller,
2. Command must dispatch new "notify view" events thru the front Controller to the view controller

This solution creates a proliferation of view controllers and is useful ONLY when multiple views want to listen to the same event and be notified simultaneously. A custom event bridge or a traditional databinding approach would be more practical for such situations [but that is another article]. In fact, in most scenarios, the view simply wants the notification directly and singularly.

As a result, ViewControllers are not the solution! There is a simpler - and better - solution to the issue; a solution that we have used successfully on many Universal Mind projects.

!! Use callbacks to serve as proxy responders for a view's cairngorm events !!

Question: "Can you say that in English?"
Answer:    Allow the view to submit itself as a responder to the event processor [e.g. command].

This solution is consistent with the approach used by the command where the command, in turn, submits itself as a responder to the delegate. The view attaches itself (via a proxy) as part of a queued chain of responders to the actual dataservices request/response.

How is this "chaining" of responders easily done? Well, when we dispatch events to commands, we create custom events. So we simply need to package a responder along with the normal event information that is dispatched to the Cairngorm framework.  If all custom events have a constructor attribute to allow transporting the responder also...

The command instance can temporarily cache the view responder/callback. Sometime later - after the asynchronous data service call responds, the following can happen:

1. the data service responses can be handled by the command to update the ModelLocator directly, trigger databindings to update, and
2. the data service responses or OTHER responses can also be forwarded by the command to the responder as to "notify" the view.

Question: "You mean my views all have to support some responder interface or be a subclass of
               some view parent class?"
Answer:   "No!  Yikes, that would be awful!"

Instead of requiring an abomination of view inheritance where all your mxml classes have to extend some base class, the view will instead create an instance of a CallBack class that will serve as a proxy responder class. Much like addEventListener(<event type>, <event handler>,...), the callback uses syntax like "new Callback(<result handler>, ,<fault handler>=null)".

Notice how the callback class does NOT know any details of the view itself. It simply has functions that may be called during an event response. And notice that the view does NOT know anything about who handles the event or how the event is processed. This "separation of concerns" is what MVC is all about. Don't forget to include this OPTIONAL callback instance as part of the event that will be dispatched.

So now let us look at some code. Below we see an example of functionality created to load user details from the server (or in a local cache). We use a custom event 'LoadUserDetailsEvent' class that accepts an optional "responder" parameter.

 private function loadUserDetails(user:UserVO):void {
       
    // notice how we "wrap" our view-level event handlers in a proxy responder instance
    // here we use something like public class Callbacks implements IResponder { ... }
    var responder : IResponder= new Responder(onResults_loadUserDetails,onFault_loadUserDetails);

    // Now simply dispatch [via controller] to the specific-command that is registered to "handle" this event
    CairngormEventDispatcher.dispatchEvent( new LoadUserDetailsEvent(user,responder) );
   }

   private function onResults_loadUserDetails(info:Object):void {
      // This is the "responder"-like result handler
      // that is called asynchronously when the command is is notified of the dataservice response
      // or synchronously if the user details were stored in a local in-memory cache

      var details : UserDetailsVO = (info as UserDetailsVO);
      ....
   }

   <mx:Button click="loadUserDetails(this.currentUser)" />

To summarize the above code snippet as psuedo-code, you (a) use a callback proxy wrapper class, (b) package the callback instance inside the event, and (c) extend the command base class to support the caching of the callback/view responder. And voila' you are done!

This is VERY clean:

1. your views are still standard mxml or as classes with aggregates and composite controls,
2. event dispatching is the same [with an optional callback] and
3. you do NOT have to create crude view controllers to handle view notifications
4. each view instance can have its OWN, separate callback
5. views can then support  modal operations, undos, reverts, commits, etc... completely independent of each other.

This solution will soon be presented to the Adobe Cairngorm committee as a candidate for incorporation into the base framework. Additionally, we will be providing this "extension" and others as a open-source extension to cairngorm. If you are interested in this and other extensions please send emails to ThomasB@UniversalMind.com or visit blog.universalmind.com.

I personally think the term system event is ambiguous. For example does " system" refer to the OS system or the FlashPlayer system or the MX Framework system... such ambiguity forces me remind the reader that these events are the Flex 2 Framework system events. In the sebsequent paragraphs, we will learn about these four event categories and how they impact our thoughts regarding Flex development.

The Flex2 framework provides superb native support for system, user, and data service events. Developers must create their own business events and must take special care to use the data service events appropriately. This 4-part guide really focuses on the concepts and uses of business and data service event categories. Before we can properly discuss such topics, however, let's first review the concepts and issues with system and user events.

We assume the Flex developer has a base familiarity with system and user events, but may not be aware of the distinctions between the system and user event categories. System events are events that are never generated directly by the user. Instead these events are generated by code activity within the mx framework; events that usually occur during application startup, component creation, component layout/measuring, and more. Such events include creationComplete, initialize, show, hide, etc.

Developers may "hook" or capture these events using built-in event stubs and custom event handlers. The event stub is the location where you specify your event handler and usually has the same name as the event itself. The Flex2 framework provides a multitude of built-in event stubs for both system and user events.

In examples 1 and 2 below the event "stub" [or hook location] is the creationComplete="". The event "handler" is the code inside the "" on the right side of the creationComplete stub. In our examples, we want to insert code that will be executed when the areaAlert component announces that its creation process is done or completed. Example 1 uses inline actionscript to specify our code. Example 2 uses specifies a custom function or method that will be executed when the event handler is invoked. If the event stub is empty [ "" ] - in other words, does not have an event handler - then the creationComplete event is still fired by the component but no event handler is executed.

Below are two equivalent examples of system event hooks:

Example 1


Example 2

Please note: as a course of "best practices", inline actionscript is fine for short 1 code segments [like above]. Explicit method calls as event handlers - e.g. announceReady() - are better used for multiple code segments. This keeps your <mx .../> tags clean and easily managed. Example 3 below shows an multi-line event handler.

Example 3

In various portions of my article I will identify features of the Flex2 platform where compiler MAGIC occurs. By this, I mean activity such as custom tags that are transparently converted to actionscript code or inline actionscript code that is converted during compiler processes... all these can be viewed as "MAGIC" because we never see it happening and it saves us - the developer - an amazing amount of manual work; thus allowing us to keep our code uncluttered with tedious details.

Earlier we stated that examples 1 and 2 are equivalent. When the Flex code in Example 1 is compiled, the inline actionscript is first converted to a distinct method [analogous to the announceReady() method shown in the script section of Example 2]. But you never see this hidden conversion process.... MAGIC!

My next posting will continue with Part 2 of 4: User Events... so stay tuned!

]]>

All too often I find great Flash applications; but their code (if published) is usually procedural and timeline-based instead of the component-based approaches that come so easily to us in Flex 2. This is to be expected since Flash 8 is a tool intended primarily for designers. While Flex is a tool oriented primarily for developers.

Porting such applications from Flash 8 to Flex 2 - where the concepts of timelines are deprecated - presents challenges. When you consider that most Flex projects are business-oriented applications that do not require dynamic stage-drawing interactions (like the Elastic Cords), then this project was the perfect impetus for me to explore and understand the conceptual differences; differences such UI interactions, tweenings, component coupling, etc..

I knew the effort would prove to be quite fun and challenging. In fact, I became obssessed first with the development efforts and then with dragging those ridiculous cords around.[So be forewarned ;-)]

Click image to run live version... requires Flash Player 9.xx

My Flex 2 version of Elastic Cords is a completely OO component-based application that uses canvases, sprites, tweens, effects, filters, bindings, and more. Run the live application and play with it. 'View Source' has also been enabled for developers to review the code, architectures, and techniques. And soon... I will provide tutorials to walk developers thru the porting process.

Interestingly enough, I had 2 options when building my Flex2 application: (1) Use a Actionscript project or (2) use a Flex project that would include the mx framework. The actionscript project would have been < 30K while the existing Flex applicaiton is ~200K. But without the mx framework, I would have lost pre-built components & containers, bindings, etc. And the resulting version is easily extendable. So the larger footprint (for the core mx libraries) was well worth it.