Flex Framework for SalesForce Apps- Part 2 The Framework

by

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

Advertisements

Tags: , ,

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: