chandra shekhar

Over 6 years of experience in Software Development including Analysis, Design and Development of various applications in Flash and Flex environment. Currently, I am associated with one of the India's leading IT company specialized in providing eLearning services, Magic Software Pvt. Ltd (http://www.magicsw.com).
In spare time I blog at http://actionscript.org and at my own weblog brupp.com

View all articles by chandra shekhar

This is fourth and conclusive part of “Getting Started” series of Cairngorm. I hope the first three parts must have shown you a door to enter to this framework. This article will brief about other parts of the Cairngorm and will leave for you to explore and getting into deep of this framework.

Lets start with the left out part of MVC, that is Model. Cairngorm encourages use of having a ModelLocator in the system (a Singleton one) though if you look at ModelLocator its not being referenced in the any other class in Cairngorm framework. So actually you have a choice here to have one or not, to have it singleton or have different model instances directly. Anyways, by definition and implementation the ModelLocator you create should implement IModelLocator interface (which is empty) and scope of this class will be having other model classes and client state maintainence. Each model or data can be then fetched by this ModelLocator.

public class SomeModelLocator implements IModelLocator
{
     ...
     public function get  mySomeViewModel():SomeViewModel
     {
          return _objSomeViewModel;
     }

}

Now lets move to the business layer which consists of delegates and services in Cairngorm. Command with help of Delegates pushes the data to the model. In simpler terms its just another class which connects a command with a service.

public class SomeDelegate
{
...
...
               public function SomeDelegate( responder : IResponder )
               {
                       this.service = ServiceLocator.getInstance()
                                          .getRemoteObject( "someServiceId" );
                       this.responder = responder;
               }

               public function getData() : void
               {
                       var call : Object = service.getData();
                       call.addResponder( responder );
               }

               private var responder : IResponder;
               private var service : RemoteObject;
...
...
}

Key points:

  1. Command instantiates Delegate.
  2. Command implements IResponder.
  3. Command knows only about delegate and provides its reference (’this’ as IResponder) to the Delegate.
  4. Delegate invokes a Service (through ServiceLocator) and adds the responder (the Command instance) to Service.

So Delegate essentially doesnt do much other than loosening the coupling. Command is only bothered about the result and not from where it is coming from. To sum up business delegates is a proxy services for Command.

Finally the ServiceLocator, its a singleton class that holds the services at one place. Any delegate can request for a service (HTTPService, WebService etc) through it.

<cairngorm:ServiceLocator
xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:cairngorm="/2006/cairngorm">

<mx:RemoteObject
id="someServiceId"
destination="servicename"
showBusyCursor="true">
</mx:RemoteObject>

</cairngorm:ServiceLocator>

This is all for what you require for getting started. I hope the series was beneficial for you. If it was; please spread the word. Share and cheer!!!.

If you need more information on above post drop a comment. Your comments are valuable and helps in molding the article so do share in.