Archive for the ‘Framework’ Category

Flex Framework for SalesForce Apps- Part 3 Working

September 18, 2010

In the last part we have seen the framework specifics. In this part lets see how it all comes together. There are several classes that we need to create. Before we get there lets look at the way the salesforce toolkit works.

There are a few toolkit classes that we need to know:

Connection: This class is responsible for communication with SFDC. Connection allows querying as well as calling webservice methods. For metadata the Connection2 class has to be used. The key methods are login() and execute()

AsyncResoponder: When a request is sent to salesforce a responder is associated to it that is responsible for handling the result/fault for that call.

Parameter: All request parameters need to be sent as an Array of objects of type  Parameter class. A vector would have been ideal in this case however the toolkit comes from Flex 3 days.

Lets look at the framework components and the end to end flow.

The core idea is MVC based where we have a controller who is responsible for making decisions on service and handling the business logic.

The fundamental approach of accessing the service is the Command pattern. This is pretty much like cairngorm except the fact that we are using the com.salesforce.AsyncResponder class for handling responses. The reason is simple. The execute method in the Connection class expects and object of AsyncResponder. Hence we can simplify the code drastically.

The Command class can be seen as a helper to the main Controller class where it takes away a responsibility from the controller of sending a particular request and handling its response. It implements an ICommand interface which includes an “execute” method. This method is responsible of sending the service call and extends from the AsyncResponder class due to which the result and fault methods need to be overridden.

All these requests are generated from a view (or other commands) where the notification travels in form of an event to the controller and based on the event the controller invokes the correct Command. This does not require the event to be of a specific type rather it can be any event with the bubbles property set to true.

RC4SF - view controller

RC4SF (View Controller Flow)

The Connector class is the service layer which in our class is a class with 2 static members. First the connection object from salesforce which can be used for login or describing an object. And second the invokeSFDC method which will call the correct webservice method.

The steps are simple:

1. Create and instance of the Controller and pass the reference of the main application

2. Dispatch an event from application with bubbles set to true

3. Create a command to handle request from the events

4. In the controller add association of the event being dispatched with the Command

5. Call the SFConnector classes invokeSFDC with correct parameters

6. Handle result/fault in the responder which called the request

Here is the code for this bit. At the end of all parts will be uploading the framework and a sample/template application

Connector class
package com.tekno.rc.service


import com.salesforce.AsyncResponder;

import com.salesforce.Connection;

public class SFConnector


public function SFConnector(){


public static var connector:Connection = new Connection	();

private static var _webServiceClass:String;

private static var _namespace:String;

public static function set webServiceClass(value:String):void{
_webServiceClass = value;

public static function get webServiceClass():String{
return _webServiceClass

public static function set namespace(value:String):void{
_namespace = value;

public static function get namespace():String{
return _namespace;

public static function invokeSFDC(method:String,args:Array,responder:AsyncResponder,webServiceClass:String="",namespace:String=""):void{

var _ws:String = _webServiceClass;

if(webServiceClass.length > 0){
_ws = webServiceClass;

var _ns:String = _namespace;

if(namespace.length > 0){
_ns = namespace;

The Control class:

package com.tekno.rc.control


import com.tekno.rc.control.commands.ICommand;

import flash.display.DisplayObject;

import mx.rpc.AsyncResponder;

public class Controller

private var app:DisplayObject;

public function Controller(app:DisplayObject){ = app;

public function mapCommandToEvent(eventName:String,responder:ICommand):void{


In the next part we see an application working with the framework. And the entire source code

Flex Framework for SalesForce Apps- Part 2 The Framework

September 9, 2010

In the last part we ‘ve looked at  basic terminology its time to take a deep dive into the architecture now. Just before we go on there is one small disclaimer here:  This is not a tutorial on how to integrate flex with salesforce, you can find a bunch of them every where, this one is to understand ways in which you can architect an application to leverage the existing arrangement.

Now that we are even, lets look at the framework, it is based on existing Rapid Connect (thank you, Abdul Qabiz for the name) framework that we use extensively and  uses 2 principles from Bruce Lee’s JKD.

  1. Use Lesser Resources (Keeping it simple)
  2. Tailor make it to your requirement

Like JKD which is a fighting philosophy which combines various methodologies (best of all worlds) we are going on a similar approach in taking best of existing framework/micro architectures and simplifying it greatly. “If its not simple, its not right.”

The core of the Framework is a simplified version of any MVC framework that you can think of, uses existing classes from the flextoolkit provided by SFDC to manage commands and responders (ala Cairngorm) and reaches them using Flex’s event propagation capability (any DI architecture like mate, swiz…) and coupling this with the requirement to push data from a non UI class to use a GenericEventDispatcher which I described in an earlier post. You may want to use this or may not want to user this.

It uses simple MVC approach:

MVC in Flex

MVC in flex regardless of the micro architecture you use leverages 2 major Flex principles.

1. Event Mechanism (invoke controller)

2. Concept of Binding (Model updates views)

However, this is a 10,000 feet view as we go deeper there are specifics and intricacies that are involved. Here  we take a closer look at the architecture we are using and then define each of its entities and see how it all comes together.

Rapid Connect for SalesForce RC4SF (Yes that’s what we are going to call it, at least for now) looks like this:

Rapid Connect 4 SalesForce

Rapid Connect 4 SalesForce

The Entities here are:

1. The View: is any UI component, typically an MXML one which can dispatch an event (with bubbles set to true)

2. The Controller: is an entity that listens to the events coming from the view and handles them

3. The AsyncResponder: is a class which is something like a command class in Cairngorm earlier versions however it uses the salesforce AsyncResonder instead of using an interface and overrides the result and fault method (Here you can decide if you want to call the service from here or you want controller to handle that part. More about this in part 3)

4. The Connector: is the class that plays a role of a service class. This class contains the SFDC connector obejects and calls methods to login, invoke a webservice method and get metadata

5. The GenericEventDispatcher: is a singleton EventDispatcher which is responsible for inter-application communication in a more effective manner (in the past people have been using Application.application for this purpose)

6. The Model: is your data store. This can be a singleton (if you are a fan of Cairngorms ModelLocator approach) or can be VO classes. You can either use binding to update the objects or use the generic event disaptch mechanism if you have to invoke something on the UI.

This broadly covers everything that we need to cover for the framework.

Up next in part 3: The working of the Framework and some code

%d bloggers like this: