Jai’s Weblog – Tech, Security & Fun…

Tech, Security & Fun…

  • Jaibeer Malik

    Jaibeer Malik
  • View Jaibeer Malik's profile on LinkedIn
  • Subscribe

  • Feedburner

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 29 other followers

  • Archives

  • Categories

  • Stats

    • 379,210
  • Live Traffic

Flex: Cairngorm View Notifications Strategies, Responders from Command to View

Posted by Jai on August 26, 2009

This post covers the different strategies you can use for view notifications during flex development using Cairngorm framework and the custom implementation of UM Cairngorm extension.

This is part of the series of posts:

Flex then, now & tomorrow – From a java developer’s perspective,

Flex: Cairngorm (MVC) , SpringActionscript (IOC) and other Cairngorm Extensions,

Flex: SpringActionscript (IOC) & SpringActionscript Cairngorm Extension Sample Code Examples

Flex Tips&Tricks

to cover different strategies in flex development using Cairngorm framework to solve different practical problems.

In this post we will see how to use presentation model for the view notification and the use of UM Cairngorm extension implementation for the view notifications. And how we can use Responders from command to view while using Cairngorm.

View Notifications using UM Cairngorm Extension strategy

The steps to implement view notification strategy:

  • Create Responder in view
  • Add responder to event
  • Cache/Store responder from event to command
  • In Command, on success/failure call back these responders
  • On view handle success/failure to control view states

View (mxml)

Create IResponder inside mxml and pass it to the event. The parameters are the custom function names you want to call back on success or failure.


...
{
...
var callbacks : IResponder = new mx.rpc.Responder(checkLoginSuccess, checkLoginFailure);
var event     : CheckLoginCredentialsEvent = new CheckLoginCredentialsEvent(userName, password, callbacks);
//Set login button state disabled
}

private function  checkLoginSuccess(data:Object):void{
//Set login button state enabled
}

private function  checkLoginSuccess(info:Object):void{
//Set login button state enabled
}
...
...

BaseEvent


public class BaseEvent extends CairngormEvent
 {

public var callbacks:IResponder=null;

public function BaseEvent(type:String, callbacks:IResponder=null, bubbles:Boolean=true, cancelable:Boolean=false)
 {
 super(type, bubbles, cancelable);
 this.callbacks=callbacks;
 }
....

The callbacks functionality can be hidden in to base event and every event needs to extend that. The  CheckLoginCredentialsEvent will extend this base event and will pass the responder to super.

If you are directly using UM extension, your event will extend UMEvent in that case.

BaseCommand


public class BaseCommand extends AbstractResponderCommand {

private namespace self;

private var viewHandlers  : IResponder = null;

override public function execute(event:CairngormEvent):void {
      super.execute(event);
      cacheCaller(event);
      executeCommand(event);
 }

private function cacheCaller(event:Event):void {
     viewHandlers = getResponderFor(event);
 }
private function getResponderFor(event:Event):IResponder {
      var results : IResponder = null;
     if (event != null) {
        if (event is BaseEvent){
            results = (event as BaseEvent).callbacks;
        }
     }
  return results;
 }

self function result(info:Object):void {
      if (viewHandlers && (viewHandlers.result != null)) {
             viewHandlers.result(info);
     }
 }

self function fault( info:Object ) : void {
     if (viewHandlers && (viewHandlers.fault != null)) {
         viewHandlers.fault(info);
    }
 }

override public function result(data:Object):void {
      processResults(data);
      notifyCaller(data);
 }

override public function fault(info:Object):void {
     processFault(info);
     notifyCaller(info);
 }

public function notifyCaller(results:* = null):void {
   if (results is FaultEvent) {
      self::fault(results);
   }
  else{
     self::result(results);
  }
}
...
...
}

The base Command here provides you the functionality to hide the view notification implementation. It checks if the responders are attached to the event, call the responder custom functions.

CheckLoginCredentialsCommand


public class CheckLoginCredentialsCommand extends BaseCommand
 {
 public function CheckLoginCredentialsCommand () {
 super();
 }
override public function executeCommand( event : CairngormEvent ): void
 {
 //Call delegate etc.
}

override public function processResults( data : Object ) : void
 {
 //Process the results here
}
....
...
}

You can achieve multiple strategies here to have the application specific fault handling strategy in base Command.

The advantages of using this strategy explicitly is that you dont need to extend multiple classes from each Cairngorm extension to achieve the same. In case you are already using some other Cairngorm extension like SpringActionscript Cairngorm extension means you already extending another base class then either you need to extend UM extension based base command or use the strategy. Depending on what suits you best these frameworks provides you the different ways to do the same job. In this example we have covered how we can use the UM view notification strategy with out directly using the extension.

Have a look at Responders for View Notifications for UM implementation, how you can directly use UM extension to do the same job.

Presentation Model

Have a look at the idea behind the presentation model . Use the model binding strategy to control button states, component visibility and to show success/failure messages on the view etc. and in the Command set these states for the view. Store the view state in the presentation model and control this model from different commands.

Hope this will help you to implement the view notification strategy in your application. Feel free to share if you have implemented same using some different approach.

Next—>Stay tuned for the following few more posts:

-Flex Data Transfer Strategies

-Flex Client side permissions based security implementation

2 Responses to “Flex: Cairngorm View Notifications Strategies, Responders from Command to View”

  1. Ram on RIA said

    Thanks very much! It helped me

  2. Leonardo Nunes said

    Thanks from Brazil!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: