Archive for category tutorial

Swiz Passive View Example :: Part 2

Posted by brianr in flex, swiz, tutorial on January 7th, 2010

Introduction

After implementing Part 1 of the Swiz + Passive View (PV) Example, I immediately decided that one thing I missed from the original Spring ActionScript (SAS) version was the ability to create services in an XML file that’s loaded at runtime, thus allowing you to take your app from one environment to another and simply change the XML as opposed to recompiling. Some devs don’t seem to care about this, but I find it quite useful and so do many of my clients so I created a simple DynamicServiceLocator (SL) class and “injected” it into my Example.

Tutorial Goal: Create a Dynamic Service Locator that Instantiates Services from an External XML File at Runtime

Assets

Acronyms

PV = PassiveView
SAS = Spring ActionScript
SL = Service Locator
VM = View Mediator
CG = Cairngorm
IoC = Inversion of Control
DTO = Data Transfer Object

Caveats

Please read the previous posts in this series to get up to speed:

Part 1 of the Swiz + Passive View (PV) Example

I won’t go into the details of what Swiz is and how it works as I’d like to let the code speak for itself and you can just hit up the Swiz homepage and view their simple examples; that said, I’ll point out several things I really like about Swiz.

I am using Swiz 0.6.4, as I found issues with the 1.0.0 alpha release (that I’m going to bring up with Ben Clinkenbeard).

Getting Started

The idea is simple:

Create an XML file that defines all of the services leveraged in the app.
Add the DynamicServiceLocator to the BeanLoader (Beans.mxml) and give it the URL to load the services XML file.
Listen to the DynamicServiceLocator’s complete event, indicating that the services are loaded and parsed, and start the app up.
Inject the SL into the Delegates as opposed to injecting the services directly (that were previously defined and hardcoded in the BeanLoader from Part 1).
In the Delegate, request a service from the DynamicServiceLocator via an ID that was set in the service’s definition in the XML file.
Use the service.

Let’s take it piece by piece…

Step 1: Create Services XML File

Let’s start by creating an XML file called services.xml and putting it in src/assets/service-locator/. Next, let’s add some services — truth be told, I took the format for the XML that defines a service directly from the idea behind the application context files used in SAS and then created my own Object Factory…it’s very simple mind you b/c I didn’t need a huge object factory taking up a ton of memory when the only objects it would ever create were 8 different services.

<?xml version="1.0" encoding="utf-8"?>
<objects>

<!-- =================================================================== -->
<!-- SERVICE LOCATOR -->
<!-- =================================================================== -->

<!-- =================================================================== -->
<!-- This application context defines multiple test configurations, it
can be expanded to include a deployment configuration as well,
please see comments below.

1. Local Testing: XML Services
2. Dev Server Testing: XML Services
3. Deployment: XML Services
-->
<!-- =================================================================== -->

<!-- =================================================================== -->
<!-- 1. LOCAL TESTING: XML Services -->
<!-- =================================================================== -->

	<object id="loginService" class="mx.rpc.http.mxml.HTTPService">
		<property name="url" value="assets/xml/login.xml" />
		<property name="resultFormat" value="e4x" />
		<property name="method" value="GET" />
	</object>

	<object id="employeeService" class="mx.rpc.http.mxml.HTTPService">
		<property name="url" value="assets/xml/employee_list.xml" />
		<property name="resultFormat" value="e4x" />
		<property name="method" value="GET" />
	</object>

</objects>

The idea is to create a list of services as object nodes. Start by giving each <object> node a unique id attribute, as this is the key we’ll use to request the service later. The following line defines the loginService:

<object id="loginService" class="mx.rpc.http.mxml.HTTPService">

Next, define the concrete Flex service type in the class attr — right now the service class must be one of the following types:

mx.rpc.http.mxml.HTTPService
mx.rpc.http.HTTPService
mx.rpc.remoting.mxml.RemoteObject
mx.rpc.remoting.RemoteObject
mx.rpc.soap.mxml.WebService
mx.rpc.soap.WebService

Finally, add any additional properties you want to define for the service as <property> nodes with the name and value attrs matching properties that are available for the service type. The following line adds the url property for the HTTPService:

<property name="url" value="assets/xml/login.xml" />

Step 2: Add DynamicServiceLocator to the BeanLoader

We’ll add the SL to the BeanLoader just like we did for all the other objects we want managed by the IoC Container, except we’ll also provide her with the URL to our services.xml file that we just created. When the url property is set on the SL, it will automatically load the services, parse the XML, instantiate a service for each <object> node it finds that matches one of the aforementioned service classes, and then adds that service to it’s hash or Dictionary object’s list of services via the id as it’s key.

<service:DynamicServiceLocator id="serviceLocator" eventDispatcher="{this.dispatcher}" url="assets/service-locator/services.xml" />

The other thing to make note of is that we’re again passing a reference to the BeanLoader’s dispatcher so the SL can broadcast events to other objects in the Swiz IoC Container.

Step 3: Listen to the SL’s Services Load Complete Event

Since this is more of an application level event, we’ll make the ApplicationController object handle this event:

[Mediate( event="serviceLocatorServicesLoadComplete" )]
public function onServiceLocatorLoadComplete():void
{
	logger.debug("onServiceLocatorLoadComplete");

	this.eventDispatcher.dispatchEvent(new DynamicEvent("showMainView"));
}

Which then in turn broadcasts a “showMainView” event that’s handled by the ApplicationViewMediator and ultimately removes a simple preloader (which is there in case the SL should take any significant amount of time to load and parse — unlikely here, but useful in the future) and adds the MainView to the stage.

[Mediate( event="showMainView" )]
public function showMainView():void
{
	logger.debug("showMainView");

	this.view.removeChild(this.view.progressBar);
	this.view.addChild(new MainView());
}

Now this may seem like overkill for this extremely simple example, as I could have just listened to the “serviceLocatorServicesLoadComplete” in the ApplicationViewMediator, but I wanted to proxy the event through the ApplicationController in case more needed to be done…What if we wanted to update a model level var to indicate that the SL was complete? What if we wanted to tell other objects that the SL was complete?…we wouldn’t want to do that from the ApplicationViewMediator as it’s sole purpose is to lend a hand to the MainView UI component and not to orchestrate application level processing, work, etc. Again, overkill in this example, but I wanted to put it in here as an example of what you might want to do in a much larger application.

Step 4: Inject the SL into the Delegates

Next we’ll want to inject the SL into the Delegates as opposed to injecting the hardcoded services defined in the BeanLoader. First, let’s declare the new serviceLocator property for the Delegate:

[Autowire(bean="serviceLocator")]
public var serviceLocator:DynamicServiceLocator;

Next, let’s remove the service var’s declaration and create a simple getter method for it instead:

public function get service():HTTPService
{
	return this.serviceLocator.getMXMLHTTPService("loginService");
}

Step 5: Request Service From SL

This allows us to leave the actual use of the service property untouched in our service method calls - this code hasn’t changed from Part 1, but I’m showing it for clarity. We’ll look at the Login Delegate for example:

public function login(dto:LoginDTO):AsyncToken
{
	logger.debug("login");

	return this.service.send();
}

Wrapping Up

The only other thing that I failed to mention that’s different from Part 1 is the use of a simple ProgressBar component in the Application root to provide the user with some additional feedback while the SL is loading and parsing. If you look at the main application file EmpMgmtConsoleSwizPassiveView you’ll notice that the MainView is now replaced by the ProgressBar component — once the SL is complete the ProgressBar is removed from the stage and the MainView is added (as mentioned in Step 3).

Finally, to test out the dynamic SL, open up the services.xml file in the example source code and comment out the first set of services that point to local, project-level XML files and ucomment the services that point to the WASI server. See, no recompiling.

And that about does it. Any questions?

Tweet This Post

design-pattern, passive-view, service-locator

No Comments

Swiz Passive View Example :: Part 1

Posted by brianr in flex, swiz, tutorial on January 6th, 2010

Introduction

If you followed my previous posts on the Employment Management Console application leveraging Spring ActionScript + Cairngorm, then you’ll be familiar with this small example as I simply ported it over from SAS + CG to Swiz using the Passive View (PV) design pattern.

Tutorial Goal: Create an Employee Management Console using Swiz and the Passive View Design Pattern

Assets

Acronyms

PV = PassiveView
VM = ViewMediator
CG = Cairngorm
IoC = Inversion of Control
DTO = Data Transfer Object

Caveats

I am using Swiz 0.6.4, as I found issues with the 1.0.0 alpha release (that I’m going to bring up with Ben Clinkenbeard).

As an additional side note, I chose the PV because I was always a fan of code-behind — I like separation of concerns so much that I actually detest looking at MXML with ActionScript in it — what a mess!..that and the fact that MXML is declarative and should just perform basic UI layout and not presentation logic. What I love about the PV is that it relies on composition as opposed to inheritance (ie the biggest issue I have with code-behind).

Finally, there are other examples of the PV + Swiz out there, like Ben Clinkenbeard’s example, but I went ahead and created an AbstractViewMediator that takes care of some race conditions when working with Views in a ViewMediator, like setting event handlers and data bindings. And I did some other things that I didn’t see in others that I’ll point out.

Swiz is Noninvasive

Swiz is a noninvasive framework that allows you to provide well organized structure and architecture to your app without writing a ton of boilerplate code that can be overly verbose and time consuming. Remember CG and how you were forced to do the following for service calls:

Create an Event that extends the CairngormEvent.
Create a Command to act as a responder for your service call.
Create a corresponding Delegate that actually makes the service call and transforms your data to client-side types before returning it to the Command.
Don’t forget to map your Custom CG Event to your Command in the FrontController.
Wash, rinse, repeat…and repeat…and repeat…and…mehhh

With Swiz, you can (and I emphasize can b/c you can still do it the old school way too) just broadcast a DynamicEvent from any object in the IoC Container (those objects that are defined in the Swiz BeanLoader — in my example, it’s in the class Beans.mxml) and then add some metadata to another object in the Container to “Mediate” that event.

Here’s an example — so in my LoginViewMediator I want to broadcast a “login” type event and pass the username and password along with it and I want my LoginController to handle this event:

private function submitBtnClickHandler(evt:MouseEvent):void
{
logger.debug("submitBtnClickHandler");

var dto:LoginDTO;

// create a login dto to contain the required fields for login
dto = new LoginDTO();
dto.userName = this.view.userNameTextInput.text;
dto.password = this.view.passwordTextInput.text;

var dynEvt:DynamicEvent = new DynamicEvent("login");
dynEvt.dto = dto;
this.eventDispatcher.dispatchEvent(dynEvt);
}

And now we handle this event in the LoginController like so:

[Mediate( event="login", properties="dto" )]
public function login( dto:LoginDTO ):void
{
logger.debug("login");

// TODO - make service call -- see in example src code
}

So let’s dig a bit deeper here and note all the cool stuff that’s going on and why I’m psyched about Swiz + PV:

No Custom Events (If You Don’t Want To)

Notice that I didn’t have to create a custom Event — less code — YES! Now, you can by all means create a custom event and Swiz will type check the event object and the event type to make sure they exist — check it out in the Swiz Docs for Event Handling — or you can save yourself some extra code and do what I did. While I’m usually a stickler for strongly typed objects, sometimes you have to ask yourself it it’s not just overkill for something as simple as this…personally preference I suppose, but less code without sacrificing organization and good practices wins that battle in my head.

Event Mediation

Swiz automatically handles the event and passes the meat of the event (the LoginDTO that I packages in my DynamicEvent) for me…uhm, yeah…that’s frigging cool! And you can pass multiple args as well. Again, see Swiz Docs. NOTE: One thing to remember about event mediation is that the handler method must be marked public — I’m used to making event handlers protected (and sometimes even private), but this won’t allow the Swiz event mediation to work it’s magic so make sure event handler methods are marked as public.

No Logic in MXML

My LoginViewMediator grabs the username and password from it’s corresponding LoginView and creates the event and DTO. The actual LoginView is just MXML…nuff said.

Event Dispatching and Handling Thereof in IoC Container Objects

Notice that the LoginViewMediator broadcasts the event from a class member variable called “eventDispatcher”. This next part is important: in order for Swiz to Mediate events, the events need to go through the central event bus using Swiz.dispatch(<eventType>) or by using the event dispatcher in the BeanLoader — I have chosen the latter. Why?…I have 2 reasons:

I don’t like having a reference of Swiz in my classes — it’s just unnecessary and makes my application that much more coupled to the framework, something Swiz tries to get developers away from to begin with.
The Swiz.as class is a singleton and singletons are bad…this is too long a topic to get into, but my main reason has to do with the use of Modules in large Flex apps and while this example doesn’t require modules, I’d still rather just stay the hell away from singletons.

I shove a reference of the BeanLoader’s eventDispatched into my IoC Container managed objects like this:

<controller:LoginController id="loginController" eventDispatcher="{this.dispatcher}" />
<mediator:LoginViewMediator id="loginViewMediator" eventDispatcher="{this.dispatcher}" />

Note that they both don’t need it in order for the controller to hear events from the view mediator — just the object broadcasting the event needs to have a reference to it, but I pushed it into the controller as well as since I’m broadcasting other events from it that I’d like other managed objects to listen to via mediation.

AbstractViewMediator

Since all of my views need a reference to their corresponding view, I decided to create a super class for all the mediators called AbstractViewMediator. This bad boy does several things starting with the injection of the view:

[Autowire( view="true" )]
public function set view( value:* ):void
{
logger.debug("AUTOWIRE :: view = " + value);
this._view = value;

// determine if the view has been initialized...
// NO...listen for it;s creation complete event
if(this._view.initialized == false)
{
this._view.addEventListener(FlexEvent.CREATION_COMPLETE, onCreationComplete);
}
// YES...call the init() method to kick off the instation of the view mediator
else
{
this.init();
}

// don't get in GC's way if the view is removed
this._view.addEventListener(Event.REMOVED_FROM_STAGE, cleanup);
}

Again, there’s a couple things to note about this method:

The argument for the method is untyped, so how does the concrete ViewMediator (VM) know how to inject the correct view? And then what about code-hinting for the view in the VM? Well, if you look at an actual implementation of a VM, like the LoginViewMediator you’ll see the following method:
```
public function get view():LoginView
{
return this._view as LoginView;
}
```
Put this into method into each concrete VM with it’s corresponding view type and you’re good to go! Problem solved.
We check to see if the view has been initialized, ie, has the creationComplete event fired and can I start to work with children components of this view without getting runtime errors. If it has, then we call the init() method (which can and should be overridden by concrete VMs to initialize themselves); if not, then we listen for the creationComplete event and call the init() method then and only then. This ensures that when we want to set event handlers and data bindings on the view’s children we know they exist and we don’t hit nulls leading to runtime errors.
Finally, if you look at the init() method in the AbstractViewMediator, you’ll see that it also calls the setViewListeners() and setViewDataBindings() methods — these are placeholder methods where developers can again add concrete event handlers and data bindings in VM subclasses by overriding them.

The last thing the AbstractViewMediator does is provide the event dispatcher class member variable that we discussed earlier: public var eventDispatcher:IEventDispatcher;

Controllers & Delegates

In Swiz, we eliminate the idea of a Command class (from Cairgorm) and kind of replace it with the controller — I say kind of b/c it’s not exact mapping as the Cairngorm Command follows the actual J2EE Command design pattern whereas Swiz uses a controller to handle events from the UI to make service calls, act as a responder for the service calls, and finally to orchestrate what happens in the app after the service call (usually by dispatching an event). Since we already looked at the event mediation of the in the LoginController we won’t discuss that, but we will dig into how the controller leverages a corresponding LoginDelegate to call the service and perform data transformations on the service’s response object. So let’s look at the internals of the actual login event mediation in the LoginController:

[Mediate( event="login", properties="dto" )]
public function login( dto:LoginDTO ):void
{
logger.debug("login");

var call:AsyncToken = this.delegate.login(dto);

// I created 2 ways to handle the login service delegate
// you can either have the result come back to the controller
// or you can catch the result in the delegate and have it perform
// the necessary data transformations (traditional approach) before
// kicking it back to this controller via an event

// APPROACH 1) have the results come back directly to this controller
//this.executeServiceCall(call, onLoginResult, onLoginFault);

// APPROACH 2) have the results come back the delegate for data transformations
// before coming back to this controller
this.executeServiceCall(call, this.delegate.result, onLoginFault);
}

Out of the box, Swiz recommends that the controller handle the actual service response and data transformations before deciding what the app should do next…that’s too much responsibility for one object in my opinion, so as you can see I decided to allow the LoginDelegate to handle the actual service response: this.executeServiceCall(call, this.delegate.result, onLoginFault);. After the delegate finishes with the response, it dispatches an event:

LoginDelegate

public function result(resultEvent:ResultEvent):void
{
logger.debug("result");

var userModel:UserModel;
var xml:XML;
var dynEvt:DynamicEvent;

// get the response typed as desired
userModel = this.getTypedResponse(resultEvent);

// let something know that the login delegate is done
dynEvt = new DynamicEvent("loginDelegateComplete");
dynEvt.userModel = userModel;
this.eventDispatcher.dispatchEvent(dynEvt);
}

And then the event is mediated by the LoginController where it updates the necessary model properties and dispatches an event to signify the end of the login process.

[Mediate( event="loginDelegateComplete", properties="userModel" )]
public function completeLogin(userModel:UserModel):void
{
logger.debug("completeLogin");

var role:String;

// populate the model with data from the response DTO
this.appModel.user = userModel;

// determine of user is an admin
for each ( role in userModel.rolesList )
{
if(role == RolesConstants.ROLE_ADMIN)
{
this.appModel.user.isAdmin = true;
break;
}
}

// set this last as this is what binds the view change
this.appModel.isUserAuthenticated = true;

var evt:DynamicEvent = new DynamicEvent(EVENT_LOGIN_COMPLETE);
this.eventDispatcher.dispatchEvent(evt);
}

I think that about covers it for this edition. Any questions?

More to come on Swiz in the future.

Tweet This Post

design-pattern, passive-view

6 Comments

Axiis Drill Down Example

Posted by admin in actionscript, axiis, data visualization, flex, tutorial on November 2nd, 2009

I’ve seen a number of requests for a drill down version of an Axiis chart. We have a current client that will need that functionality as well so I figured I’d give it a shot.

The approach I’m taking is pretty straight forward. Put a drill down layout on the stage and make it invisible initially. When the user clicks on an item in the primary chart that we want to drill in, capture the event, set a dataProvider specific to the portion of the data that represents the drill down, hide the primary layout and show the drill down layout.

Building off the familiar approach for the Axiis examples, add a few objects for the drill down layout to use

<mx:Object id=“dataProvider”/>
<mx:String id=“verticalField”/>
<mx:String id=“dataField”>date</mx:String>
<mx:String id=“labelField”>date.value</mx:String>
<mx:Object id=“drilldataProvider”/>
<mx:String id=“drilldataField”/>
<mx:String id=“drilllabelField”/>

The drill down layout can be whatever type you choose. Here I’m just going to display the data as a simple bar chart.

<axiis:HBoxLayout
      id=“drillDownLayout”
      x=“25”
      y=“0”
      showDataTips=“true”
      height=“{dc.height-70}”
      width=“{dc.width-25}”
      visible=“false”
      dataProvider=“{drilldataProvider}”
      percentGap=“0”
      dataField=“{drilldataField}”
      labelField=“{drilllabelField}”
      itemClick=“this.itemClick(event);”>

    <axiis:drawingGeometries>
       <degrafa:RegularRectangle
             id=“drillRectangle”
             x=“{drillDownLayout.currentReference.x}”
             y=“{drillDownLayout.height-vScale.valueToLayout(drillDownLayout.currentValue)}”
             width=“{drillDownLayout.currentReference.width}”
             height=“{vScale.valueToLayout(drillDownLayout.currentValue)}”
             stroke=“{colStroke}”/>

       <degrafa:RasterText
             text=“{drillDownLayout.currentLabel}”
             fontFamily=“Arial”
             align=“center”
             x=“{drillDownLayout.currentReference.x}”
             width=“{drillDownLayout.currentReference.width}”
             y=“{drillDownLayout.height+5}”/>
     </axiis:drawingGeometries>
</axiis:HBoxLayout>

The only real piece of interest in this is the addition of a handler for the itemClick event.

itemClick="this.itemClick(event)"

Here’s the code that will handle the click of an item in the layout. Note that it will check to see which layout is currently visible so we can get back to the primary chart.

public function itemClick(evt:LayoutItemEvent):void
{
       // Switch back to main view
       if ( this.drillDownLayout.visible )
       {
            this.drilldataProvider = null;
            this.drillDownLayout.visible = false;
            this.hLayout.visible = true;
            dc.invalidateDisplayList();
         }else {
             var ac:ArrayCollection = evt.item.layout.dataProvider as ArrayCollection;
             this.hLayout.visible = false;
             this.drillDownLayout.visible = true;
             this.drilldataField = &amp;quot;value&amp;quot;;
             this.drilllabelField = &amp;quot;value&amp;quot;;
             this.drillRectangle.fill = ( evt.item.data.type == "receivables" ) ? this.receivablesStack.fill : this.payablesStack.fill;
             this.drilldataProvider = ac;
             dc.invalidateDisplayList();
        }
}

Tweet This Post

No Comments

Axiis Examples with Lots of Comments

Posted by admin in actionscript, air, data visualization, flex, tutorial on October 17th, 2009

We’ve begun using Axiis on a current client’s project. The application is loaded with graphs and charts and when we hand off the project, we needed to provide a framework for the development staff to quickly build and add new graphing components. Some of the charts are simple but there are some more complicated ones we need to build and will be built in the future. The current Flex DataViz components work fine for simple tasks. But, anyone who has had to go beyond the basics understands the pain that you quickly begin to feel.

Fortunately, I caught Tom Gonzalez’s, (BrightPoint Consulting) lecture at MAX this month and was blown away. The things they’re doing with the Axiis framework and Degrafa are off the charts! (pun intended)

I’ll leave the real discovery to you to check out the Axiis site, but, Axiis is a ’specialized framework that implements specific design patterns that can be used to create your own visualizations’. It’s not a pre-built collection of charting components. They’ve developed a great way of abstracting the basic building blocks of doing data visualization.

Axiis is currently in beta release. There are a lot of great examples on their site so check them out. If you’re new to Degrafa, it’s worth your while to do a bit of reading and check out the cool examples they have on their site as well since many of the examples use Degrafa.

Being in beta, the documentation is a work in progress. The examples from the site are great and really cover a lot of space, but I did struggle with some of the concepts at first. So I’ve taken three of the first examples we needed to borrow from and hyper-commented them for clarity.
I’ll continue to add to the collection over time.

Cluster Stack Example

Linear Series Example

Cluster Column Example

Tweet This Post

axiis, data visualization, flex

2 Comments

Flex + Cairngorm + Spring ActionScript Part 5 Announcement

Posted by brianr in cairngorm, spring, tutorial on June 26th, 2009

UPDATE: I’ve decided not to continue this tutorial at the moment as I’m really digging the lightweight, simple elegance, and less complicated Swiz framework. I will finish the path of this original tutorial and dig into BlazeDS + Spring + etc, but with the obvious replacement of Swiz over SAS + CG. Sorry for the confusion and delay.

I’m going to release Part 5 of the series shortly, although it’s taking a slight deviation from what I had planned originally…

The Spring AS (”SAS”) framework has been changing quite a bit and they’ve released new versions and new docs for both the framework itself and the Cairngorm (”CG”) extensions, so I’d like to revisit my SAS + CG implementation leveraging their approach.

I’ve also added in a login screen to set up the use of Spring Security with role based permissions on the Java side — it also allows me to illustrate the use of multiple Cairngorm Events + Command + Delegate paths with both hardcoded AS and XML Delegates.

The actual code is done, now I just have to write about it…I’m about 3/4 of the way through the actual post explaining the code, but it’s Friday and I need a beer so here’s the code to tide those waiting on it over. Again, the full blog post with details explaining the ins and outs to come some time next wk.

Assets:

Previous Tutorials:

Stay tuned for the real Part 5 in the series.

Tweet This Post

cairngorm, flex, spring-actionscript, tutorial

7 Comments

Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Hibernate + MySQL Tutorial Part 4

Posted by brianr in blazeds, eclipse, flex, java, tomcat, tutorial on June 11th, 2009

Introduction

I’ve been playing around with a stack of Flex/ActionScript and Java frameworks and finally came up with one that I’m really pleased with — since I’m reusing these terms throughout the series, please review the acronyms after each, as that’s how I’ll be referring to them in the tutorial:

Flex
Cairngorm (”CG”)
Spring ActionScript (”SAS”), formerly Prana
Tomcat (”TC”)
WebORB (”WORB”) / BlazeDS (”BDS”)
Spring, Server-side Java version
Hibernate (”HB”)
MySQL

To that, I’m planing on writing a series of tutorials where each one builds on the previous one. The final tutorial will cover: Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Spring Security + Hibernate + MySQL

Part 4 in our series is really just a setup post that lays the groundwork for hooking in BlazeDS (”BDS”) or WebORB to our existing app which we’ll do in Part 5 — I started to put Flex + Tomcat + BDS/WebORB integration all in one post, but it started getting really long — instead we’ll just focus on creating a Java-based Dynamic Web Project with Eclipse Web Tools Platform (”WTP”) and then modifying our existing Flex project to build and deploy to our new Java project.

Tutorial Goal: Create a new Dynamic Web Project integrated with Tomcat & modify our previous Flex Project to build and deploy to it.

This is extremely basic for seasoned Java developers, but I thought it would be necessary for those that wished to learn how to integrate a Flex project with a Java project inside one Eclipse IDE.

Assets:

NOTE: Usually I provide a working demo, but since it’s not really any different than Part 3 and I didn’t have time to deploy to our Amazon EC2 Tomcat box, I’ll come back to it at a later date.

Prerequisites & Assumptions

Already have Eclipse WTP (or a similar Eclipse based Java IDE) that allows you to create Dynamic Web Projects that integrate with Tomcat.
Basic understanding of Java development and deployment into a web container.

What This Tutorial is Not

This tutorial will not provide details on installing Eclipse WTP or other Eclipse based Java IDEs — go here to get a copy of WTP. In addition, it will not focus on Java best-practices, but rather get the developer up to speed quickly on the integration of Flex, WTP, and Tomcat.

NOTE: Most of the code snippets are truncated to be concise and only highlight the lines of code that truly deserve the readers attention, so it’s highly recommended that readers download the accompanying project source files in order to follow along.

Download Tomcat Server

To start things off we’ll simply download Tomcat so we have our application server ready to rock when we start creating our Java project. Go here and download the latest version of the Tomcat server as a zip. At the time of writing this Tomcat 6.0.18 was the latest release.

As a side note, I usually stick all of my servers and app server frameworks on my local hard drive in something like this (just in case you’re trying to stay organized like me):

Location of Tomcat on Local HD

Once it’s finished downloading unzip that sucker and we’ll move on to creating the Java project.

Create a Dynamic Web Project (Java)

Start by changing your perspective to the Java EE Development perspective and then create a new Dynamic Web Project called EmployeeManagementConsoleJava4 in the same workspace as the Flex projects from the earlier tutorials (Part 1, Part 2, Part 3) — you can combine your Flex and Java project into one project (it’s an option when you first create your Flex project), but since we started with a plain old Flex project we’ll keep them separate for the remainder of this tutorial.

The Java4 suffix will just help us indicate that it’s mapped to the EmployeeManagementConsole4 Flex project we’re going to create, as well as the new projects we’ll create in subsequent tutorials.

When you create your new Java project, you’ll be presented with the option to add a server to this project, so here we’ll select the “New” button and browse to our recently downloaded Tomcat server installation — choose Apache Tomcat v6.0 and browse to the tomcat directory we unzipped above:

Dynamic Web Project Tomcat Setup

Click Finish and close out the creation of your Java project — we’ll just keep all the defaults to make things uber simple.

Test Java Project with Tomcat Integration

Start by creating a new index.html file in the WebContent folder in your new Project and toss in “Test” for both the title and the only node value in the <body> tag:

index.html in WebContent

And even though we haven’t written any Java, let’s test deploy our application to the server and start her up.

Down in your Server View of Eclipse (if you don’t see the server view, just goto Window -> Show View -> Servers), right-click on the new server we just created and and select “Add and Remove Projects…” and select your new EmployeeManagementConsoleJava4 and click the Add button — you should see the project show up on the right column, indicating it’s been added to the server:

Add Project to Tomcat

Now start your server by right-clicking on it and selecting Start — you should see the console start to fill up with logging info from the server and hopefully no errors. If you do, try going through the console’s list of errors and fixing them.

At this point I’ll assume you don’t have any errors and you’re ready to test your simple Java project — right-click on index.html and select Run As -> Run on Server and you should see your index page open up in Eclipse’s default browser. The other option is to open up your favorite browser and entering in the following URL:

http://localhost:8080/EmployeeManagementConsoleJava4/index.html.

At this point you should see a white page with the sole word “Test” that we added to our index.html page.

Next we’ll move back to the Flex side and change our Flex Project’s settings to build and deploy to our new Java project.

Create a Server-Based Flex Builder Project

If you don’t already have the project from Part 3 of this series, please download it and import it into Flex Builder (”FB”). Once in FB, copy and paste it into the same workspace as EmployeeManagementConsoleJava4.

NOTE: If you don’t feel like writing all this from scratch, just download my project for Part 4 — listed above.

Modify the Project Property Files

Since we started our Flex project as a non-server based project, we’ll need to make some modifications to our .project, .actionScriptProperties, and .flexProperties files in order to convert the project to a server-based application. These files all exist under the root of the Flex Project’s directory — if you can’t see them, make sure you’re in either the Flex or Flex Debugging Perspective.

As a side note, under the covers we’re modifying the Flex Project’s Properties as if we right-clicked on the project and selected Properties.

.actionScriptProperties

Open up .actionScriptProperties and locate the <compiler> node and add or change the following attributes to look like this:

outputFolderLocation=”DOCUMENTS/EmployeeManagementConsoleJava4/WebContent/flex”
rootURL=”http://localhost:8080/EmployeeManagementConsoleJava4/flex”

Your .actionScriptProperties should look like this:

<?xml version="1.0" encoding="UTF-8"?>
<actionScriptProperties
	mainApplicationPath="EmployeeManagementConsole4.mxml"
	version="3">

<compiler
	additionalCompilerArguments="-locale en_US
	-use-network=false"
	copyDependentFiles="true"
	enableModuleDebug="true"
	generateAccessible="false"
	htmlExpressInstall="true"
	htmlGenerate="true"
	htmlHistoryManagement="true"
	htmlPlayerVersion="9.0.124"
	htmlPlayerVersionCheck="true"
	outputFolderLocation=
		"DOCUMENTS/EmployeeManagementConsoleJava4/WebContent/flex"
	outputFolderPath="bin-debug"
	rootURL="http://localhost:8080/EmployeeManagementConsoleJava4/flex"
	sourceFolderPath="src"
	strict="true"
	useApolloConfig="false"
	verifyDigests="true"
	warn="true">

<compilerSourcePath/>
<libraryPath defaultLinkType="1">
<libraryPathEntry kind="4" path=""/>
<libraryPathEntry kind="1" linkType="1" path="libs"/>
</libraryPath>
<sourceAttachmentPath/>
</compiler>
<applications>
<application path="EmployeeManagementConsole4.mxml"/>
</applications>
<modules/>
<buildCSSFiles/>
</actionScriptProperties>

.flexProperties

Open up .flexProperties and locate the <flexProperties> node and add or change the following attributes to look like this:

flexServerType=”2″
serverContextRoot=”/EmployeeManagementConsoleJava4″
serverRoot=”${DOCUMENTS}/EmployeeManagementConsoleJava4/WebContent”
serverRootURL=”http://localhost:8080/EmployeeManagementConsoleJava4/”

Your .flexProperties should look like this:

<?xml version="1.0" encoding="UTF-8"?>
<flexProperties
	flexServerType="2"
	serverContextRoot="/EmployeeManagementConsoleJava4"
	serverRoot="${DOCUMENTS}/EmployeeManagementConsoleJava4/WebContent"
	serverRootURL="http://localhost:8080/EmployeeManagementConsoleJava4/"
	toolCompile="true"
	useServerFlexSDK="false"
	version="1"/>

.project

Open up .project and locate the <projectDescription> node and add the node <linkedResources> after the <natures> node inside <projectDescription> — simply copy and paste the <linkedResources> node from my code snippet below; your .project file should look like this:

NOTE: You need to put the full, absolute path on your machine to your Java Web Project in place of the @@FULL_PATH@@ key I subsituted down below for the path on my machine.

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
	<name>EmployeeManagementConsole4</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
		<buildCommand>
			<name>com.adobe.flexbuilder.project.flexbuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
	</buildSpec>
	<natures>
		<nature>com.adobe.flexbuilder.project.flexnature</nature>
		<nature>com.adobe.flexbuilder.project.actionscriptnature</nature>
	</natures>
	<linkedResources>
		<link>
			<name>bin-debug</name>
			<type>2</type>
			<location>
		@@FULL_PATH@@/EmployeeManagementConsoleJava4/WebContent/flex
			</location>
		</link>
	</linkedResources>
</projectDescription>

Check Flex Project Properties

Just to make sure we did everything correctly, let’s check the project properties by right-click on our Flex Project and selecting Properties -> Flex Build Path. It should look like this:

Main source folder: src
Output folder: ${DOCUMENTS}/EmployeeManagementConsoleJava4/WebContent/flex
Output folder URL: http://localhost:8080/EmployeeManagementConsoleJava4/flex

Build Path Properties

Next let’s check the Flex Server Settings: Project Properties -> Flex Server:

Root folder: ${DOCUMENTS}/EmployeeManagementConsoleJava4/WebContent
Root URL: http://localhost:8080/EmployeeManagementConsoleJava4/
Context root: /EmployeeManagementConsoleJava4

Server Properties

Move Assets Under Source

Something we’re going to change here is the location of the assets directory — we’re going to move it from the root of the Flex project to the Flex src directory — this ensures that our assets are deployed with our Flex app everytime we build the application. If you run a build, you’ll now see that the assets directory is in the bin-debug directory at the same level as the actual Flex application:

Assets Directory New Location

This also means we’ll need to make 2 quick changes in in our Flex app that point to the location of the assets directory:

1. Open up EmployeeManagementConsole4.mxml and locate the line where we’re loading up the Spring Application Context XML config file and modify it’s path such that it’s relative to the Flex application.

private function loadSpringAppContext():void
{
	trace("Application loadSpringAppContext");

	var applicationContextURL:String;

	applicationContextURL = "assets/springactionscript/applicationContext.xml";

	// Initializes the applicationContext instance and adds listeners for the context file loading events.
	this.applicationContext = new FlexXMLApplicationContext(applicationContextURL);
	this.applicationContext.addEventListener(Event.COMPLETE, applicationContextLoadResult);
	this.applicationContext.addEventListener(IOErrorEvent.IO_ERROR, applicationContextLoadFault);
	this.applicationContext.load();
}

2. Open up applicationContext.xml and locate the line where we set the URL to the XML data and modify it’s path such that it’s relative to the Flex application.

<property name="httpService">
	<object class="mx.rpc.http.HTTPService">
		<property name="url" value="assets/xml/employee_list.xml" />
		<property name="resultFormat" value="e4x" />
		<property name="method" value="GET" />
	</object>
</property>

Build and Run the Application

Couple last things to get this thing up and running:

Run a clean on the Flex project: Project -> Clean
If you expand your Java project, you’ll see a WebContent directory and a new flex directory that was generated for us when we built our Flex project. Copy the assets directory from the root of our Flex project into WebContent
If your Server is already started, Stop it.
Right-click on the server and select Clean…
Restart your sever.
Right-click on your Flex project and select Debug As -> Flex Application
The Flex app should show up in the browser.
Click the “Refresh List” bottom to make sure it still loads the list of employees.

Your Flex app should show up in your browser and look just like Step 3’s finished tutorial, except that it’s running on the Tomcat application server.

Completed Step 4 Flex App

Stay tuned for Part 5 where we integrate Flex and BlazeDS using the RemoteObject.

Tweet This Post

13 Comments

Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Hibernate + MySQL Tutorial Part 3

Posted by brianr in cairngorm, flex, spring, tutorial on May 14th, 2009

Introduction

Flex
Cairngorm (”CG”)
Spring ActionScript (”SAS”), formerly Prana
Tomcat (”TC”)
WebORB (”WORB”) / BlazeDS (”BDS”)
Spring, Server-side Java version
Hibernate (”HB”)
MySQL

Part 3 in our series will build on our working knowledge of Spring ActionScript framework (”SAS”) and use Dependency Injection (”DI”) to add the services to our Business Delegates (”BD”) from Part 2.

Tutorial Goal: Inject Service Definitions into Business Delegates using Spring AS

Build upon the existing, foundational Flex + Cairngorm (”CG”) + SAS application and inject the desired services into our Business Delegate (”BD”) at runtime; we’ll continue working with the EmployeeXMLDelegate and inject the necessary HTTPservice and it’s properties as opposed to hardcoding them directly in the BD. After this tutorial you should know why and how to inject complex objects with SAS.

Assets:

Prerequisites & Assumptions

Ability to create Flex and ActionScript classes with Flex Builder (”FB”). NOTE: I’m actually using Eclipse WTP with the Flex Builder Plugin so I can develop in both Java/J2EE and Flex projects in one IDE.
Used or understand Cairngorm’s basic flow and how it all fits together. If you haven’t, I recommend looking at Part 1 of this tutorial and the Cairngorm Diagram for some reference.
Basic understanding of Spring ActionScript and Dependency Injection. If you haven’t, I recommend looking at Part 2.
Understanding of OOP and basic Design Patterns.

What This Tutorial is Not

There’s actually a set of extensions for SAS for both CG and PureMVC (”PMVC”), but since CG is more widely used and I want to keep things simple, this tutorial will focus on SAS + CG…so leave the frameworks debate and why I chose CG for this example for another time, or at least until another post where I actually want to argue the architectural issues that both frameworks possess. I’m also not going to focus on CG best-practices and extensions that WASI currently uses in this first post…let’s just get a SAS + CG app up and running and then come back to that in a later, cleanup/best-practices post.

Create a Flex Builder Project

If you don’t already have the project from Part 2 of this series, please download it and import it into Flex Builder (”FB”). Once in FB, copy and paste it into the same workspace as “EmployeeManagementConsole2″.

NOTE: If you don’t feel like writing all this from scratch, just download my project for Part 3.

Remove Hardcoded Service From EmployeeXMLDelegate

Open up EmployeeXMLDelegate and remove the class property httpService and it’s instantiation from the constructor. You’re BD’s constructor should now look like this:

public class EmployeeXMLDelegate extends AbstractDelegate implements IEmployeeDelegate
{
	/**
	 * Constructor.
	 */
	public function EmployeeXMLDelegate(responder:IResponder=null)
	{
		trace("EmployeeXMLDelegate Constructor");

		this.responder = responder;
	}
        ...
}

Add HTTPService Service to AbstractDelegate

Open up AbstractDelegate and add the class property httpService. You’re BD’s constructor should now look like this:

public class AbstractDelegate
{
	/**
	 * Reference to the XML / HTTP service the concrete delegate's will will use.
	 */
	public var httpService:HTTPService;

	/**
	 * Constructor.
	 */
	public function AbstractDelegate()
	{
		trace("AbstractDelegate Constructor");
	}
        ...

Notice that the httpService property was given the public modifier so that we can actually perform the DI — if it’s private or protected we can’t inject the HTTPService.

Modify the Spring ApplicationContext & Inject Services

Open the SAS Application Context (”SASAC”) file and locate the definition of the EmployeeXMLDelegate in the node <property name=”employeeDelegate”>; here’s where we’re looking to inject our HTTPService as a property of our BD. Notice the <property name=”httpService”> – it matches the exact property name of the httpService that we created in our AbstractDelegate and is where we’ll perform the DI. Just like the previously hardcoded version of our EmployeeXMLDelegate, we’ll set the following properties on our HTTPService:

url = ../assets/xml/employee_list.xml
resultFormat = e4x
method = GET

You’re SASAC file should now look somewhat like the following snippet. Note: I removed extraneous nodes (ie the DelegateLocator, etc) from this snippet to be concise; please review the accompanying files available for download or see the the project from Part 2 for more details.

ApplicationContext.xml

<?xml version="1.0"?>
<objects>
...
<property name="employeeDelegate">
	<object
	   class="com.wasi.employeeconsole.business.delegates.EmployeeXMLDelegate">
		<property name="httpService">
			<object class="mx.rpc.http.HTTPService">
				<property
					name="url"
					value="../assets/xml/employee_list.xml" />
				<property
					name="resultFormat"
					value="e4x" />
				<property
					name="method"
					value="GET" />
			</object>
		</property>
	</object>
</property>
...
</objects>

If you run the application now you’ll receive an error — this is because we haven’t included the HTTPService anywhere in the application and yet we’re trying to instantiate it at runtime. Since we ran into this issue in Part 2, I won’t go into details and you can read about it here — it refers to an issue when trying to inject a BD, but the issue is the same here with the HTTPService. What we need to do to fix the issue is to add a reference to the HTTPService in the ClassReferences.properties file like we did for the Delegates we injected.

ClassReferences.properties

Add the following to the ClassReferences file:

HTTPService = ClassReference("mx.rpc.http.HTTPService")

Compile & Run the Application

When you test your application you should see something like:

Employee Mgmt Console with XML Business Delegate

Employee Management Console with XML Business Delegate with HTTPService Injected

So now we’re back to a working application, but we’ve injected the HTTPService into our BD making it even more flexible from a configuration standpoint. If you’d like to explore this further try one of the following or both:

Move the employee_list.xml file to somewhere else in the project or file system and simply change the url property of the httpService in the Spring AS ApplicationContext file — notice that you don’t have to recompile your Flex app either, as the SASAC file is loaded at runtime.
Create a Java servlet (or .NET or PHP script) that generates the same XML structure as the employee_list.xml and change the url property of the httpService in the Spring AS ApplicationContext file to point to that dynamic XML service provider.

References:

Dependency Injection in Flex Applications - Part 1 - Spring ActionScript and Cairngorm - Allen Manning
IoC and the Dependency Injection Pattern in Flex - Eric Feminella
Christophe Herreman’s Blog - Christophe Herreman

Tweet This Post

6 Comments

Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Hibernate + MySQL Tutorial Part 2

Posted by brianr in cairngorm, flex, spring, tutorial on May 8th, 2009

Introduction

Flex
Cairngorm (”CG”)
Spring ActionScript (”SAS”), formerly Prana
Tomcat (”TC”)
WebORB (”WORB”) / BlazeDS (”BDS”)
Spring, Server-side Java version
Hibernate (”HB”)
MySQL

Part 2 in our series will focus on the introduction of the Spring ActionScript framework (”SAS”) to our existing Flex + Cairngorm (”CG”) application from Part 1.

Tutorial Goal: Flex + Cairngorm + Spring ActionScript

Build upon the existing, foundational Flex + CG application by adding SAS and injecting the desired CG Business Delegate (”BD”) at runtime; we’ll continue working with the mock-object EmployeeASDelegate, but also add a XML based BD called EmployeeXMLDelegate so we can choose our data provider at runtime. After this tutorial you should know why and how to use SAS with CG.

Assets:

Prerequisites & Assumptions

Ability to create Flex and ActionScript classes with Flex Builder (”FB”). NOTE: I’m actually using Eclipse WTP with the Flex Builder Plugin so I can develop in both Java/J2EE and Flex projects in one IDE.
Used or understand Cairngorm’s basic flow and how it all fits together. If you haven’t, I recommend looking at Part 1 of this tutorial and the Cairngorm Diagram for some reference.
Understanding of OOP and basic Design Patterns.
NOTE: Most of the code snippets are truncated to be concise and only highlight the lines of code that truly deserve the readers attention, so it’s highly recommended that readers download the accompanying project source files in order to follow along.

What This Tutorial is Not

So without any further delay, why Spring ActionScript (”SAS”)?

Ever create an app that relies on data from a DB that isn’t created or populated yet or try to work with services that don’t return any data? Sure you have, and so we all have our own frameworks and tricks for setting up mock objects in Business Delegates (”BD”) or simply consume XML until the real data is available. And that works great for awhile. You sit down with the server-side guys and flesh out your service API, the inputs and outputs, and hardcode your data in this temporary fashion until you hit the phase of your project called “integration.” What a lovely word. I’ve spent months of fun playing in the “integration phase” where you actually hook up your app to live data services, and you spend a good deal of time just ripping out scaffolding code, those hard-coded data calls, and…bleh…what a mess. So what if there was a way to simply interchange the BDs with their hard-coded mock objects, your stubbed service calls, or your XML through a simple config file? This my friends is the beauty of SAS and is why you’ll be hooked the moment you light up your first app with it.

The idea is to decouple configuration from implementation in patterns known as Inversion of Control (”IoC”) and Dependency Injection (”DI”) which are essentially the heart of Spring. Rather than go into too much detail about either of these patterns, please read Eric Feminellas great post on the topic. Furthermore, this is being very narrow minded and I’m leaving out a ton of other great things that Spring does, but this is the meat and potatoes of it and is what we’ll focus on in our first SAS tutorial.

A huge thanks to Christophe Herreman for porting this beauteous code-base over from Java to AS! SAS, formerly Prana, is now being considered as part of the original Java SpringSource Community’s code repository. Now that we have an idea of how SAS can help us, let’s see it in practice.

Create a Flex Builder Project

If you don’t already have the project from Part 1 of this series, please download it and import it into Flex Builder. Once in FB, copy and paste it into the same workspace as “EmployeeManagementConsole2″.

Add Libraries and Dependencies

Next we’ll need to add the necessary libraries and dependencies to the project as SWCs and AS files; mainly, we’ll need:

Spring ActionScript — Download the ZIP, extract it, and import the spring-actionscript.swc into the libs folder of your Flex Builder project.

Spring ActionScript Cairngorm Extensions — I couldn’t find the SWC for this, so I just downloaded the AS source by using Subversion (I’m currently using Subclipse, the Eclipse plug-in for SVN) and going here — https://src.springframework.org/svn/se-springactionscript-as/. Checkout the project “spring-actionscript-cairngorm” as a Flex Library Project. Once the project has completely checked out, disconnect it from SVN — if you are using Subclipse, just right-click on the project -> Team -> Disconnect (and delete all the SVN contents as well.) Finally, dig into the Flex Library Project you just created and locate the following directory: trunk/core/src/main/actionscript/org. Copy the root folder for the Cairngorm Exts sourcem org and all of it’s child directories and paste it into the src folder of your original EmployeeManagementConsole2 project.

Create Simple XML Data Source File

First we need to go ahead and create our XML data source, so let’s create a new XML file called “employee_list.xml” and save it in our project in a root folder called /assets/xml. We’ll model the XML directly after the EmployeeModel.as Model object (also like the AS mock-object we created in the AS BD), except that we’ll make the ID property an attribute in each employee node. We’ll also add “XML” as a suffix to each first name node value just so we can differentiate the data source later on when we start switching between the AS mock-object BD and our new XML BD. The finished XML should look something like this: employee_list.xml

<?xml version="1.0"?>
<employee id="0">
		<firstName>BrianXML</firstName>
		<lastName>Riley</lastName>
	</employee>

	<employee id="1">
		<firstName>TimXML</firstName>
		<lastName>McGee</lastName>
	</employee>

	<employee id="2">
		<firstName>JoeXML</firstName>
		<lastName>Seiter</lastName>
	</employee>

</employeeList>

Create New XML Business Delegate

Since we already have the application running with the AS mock-object BD and we want the app to work with XML as well, we need to go ahead and create a new XML BD, EmployeeXMLDelegate.as. The key differences between this BD and the AS BD are the following:

Has its own HTTPService object to make requests for the XML Employee List data.
Calls the HTTPService in the getList() method.
Deserializes the XML result into an ArrayCollection (”AC”) of EmployeeModel objects.

These changes all exist in the constructor, getList(), and result() methods.

EmployeeXMLDelegate.as

/**
 * Constructor.
 */
public function EmployeeXMLDelegate(responder:IResponder=null)
{
	trace("EmployeeXMLDelegate Constructor");

	this.responder = responder;

	// the serives are usually created in the ServiceLocator ("SL") in
	// Cairngorm but since we're going to do away with the SL when we
	// introduce Spring AS, we'll just hardcode the service here for now.
	this.httpService = new HTTPService();
	this.httpService.url = "../assets/xml/employee_list.xml";
	this.httpService.resultFormat = "e4x";
}

/**
 * Get the list of employees.
 */
public function getList():void
{
	trace("EmployeeXMLDelegate getList");

	var responder:mx.rpc.Responder;
 	var token:AsyncToken;

 	responder = new mx.rpc.Responder(result, fault);
	token = this.httpService.send();
	token.addResponder(responder);
}

/**
 * Handles the successful service request.
 *
 * @param response Object The success event coming back from the asynchronous
 * service call containing the data payload.
 */
public function result(resultEvent:ResultEvent):void
{
	trace("EmployeeXMLDelegate result");

	var response:ArrayCollection;
	var employee:EmployeeModel;

	response = new ArrayCollection();

	for each(var employeeXML:XML in resultEvent.result.employee)
	{
		employee = new EmployeeModel();
		employee.id = employeeXML.@id;
		employee.firstName = employeeXML.firstName;
		employee.lastName = employeeXML.lastName;
		response.addItem(employee);
	}

	// pass the command the response object to do whatever it wants with it
	this.responder.result(response);
}

Now that we have our XML BD, let’s make some quick changes in the CMD to test it out. We’ll need to modify the reference to the BD in 2 places in the CMD:

The delegate class property
The instantiation of that delegate in the constructor

GetEmployeeListCommand.as

public class GetEmployeeListCommand implements ICommand, IResponder
{
	private var delegate:EmployeeXMLDelegate;

	public function GetEmployeeListCommand()
	{
		trace("GetEmployeeListCommand Constructor");
		this.delegate = new EmployeeXMLDelegate(this);
	}
       ...
}

When you test your application you should see something like:

Employee Management Console with XML Business Delegate

Add Spring ActionScript

Now we have 2 possible delegates to choose from, but we have to change the AS in the CMD, recompile, and then test to see the results…this sounds tedious and leaves us with the very problem we’re trying to avoid…time for SAS.

In order to see the changes occur at run-time we’ll need to create the Spring Application Context XML configuration file that defines which BD to inject at run-time and then modify the CMD in such a way that the exact type of BD is unknown at compile time…well not exactly an unknown type, but rather the underlying implementation. To achieve this feat we’ll leverage the almighty Interface in our CMDs. We’ll come back to the Application Context config file in a bit…

Create an Employee Delegate Interface

If you look at the AS and XML BDs, you’ll notice that they both have the same method signature for getList():

public function getList():void

We’ll use this as the point of commonality to create our interface, as they both need to actually get the list of employees for our application.

IEmployeeDelegate.as

/**
 * Web App Solution Confidential Information
 * Copyright 2009, Web App Solution, Inc.
 *
 * @author Brian Riley
 * @date May, 4, 2009
 */
package com.wasi.employeeconsole.business.delegates
{
	public interface IEmployeeDelegate
	{
		function getList():void
	}
}

Next we’ll make each of our BDs implement the interface.

public class EmployeeASDelegate implements IEmployeeDelegate
public class EmployeeXMLDelegate implements IEmployeeDelegate

Spring ActionScript Application Context

The SAS Application Context (”SASAC”) is the XML configuration file that’s loaded at run-time by the Spring framework that defines all the concrete implementation objects you wish to use in your application — it essentially maps interface properties in classes (like our delegate:IEmployeeDelegate property in our GetEmployeeListCommand) to fully qualified, concrete objects. Let’s actually create our ApplicationContext and see how we can either inject our AS mock-object BD or our XML BD at run-time.

Create a new XML file called “ApplicationContext.xml” and save it in our project in a root folder called /assets/springactionscript/. Add the following code, which we’ll discuss in a moment:

ApplicationContext.xml

<?xml version="1.0"?>
<objects xmlns              = "http://www.pranaframework.org/objects"
         xmlns:xsi          = "http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation = "http://www.pranaframework.org/objects http://www.pranaframework.org/schema/objects/prana-objects-0.5.xsd">

	<!-- =================================================================== -->
	<!-- This application context defines multiple test configurations, it
		 can be expanded to include a deployment configuration as well,
		 please see comments below.

		 1. Testing: ActionScript Mock Delegates
		 2. Testing: XML Mock Delegates (Will add in next revision)
		 3. Deployment: Remote Object Delegates (Will add in next tutorial)

		 To use a configuration, uncomment it and comment the one you don't
		 want to use. By default, the Mock Delegates configuration is used.
	-->
	<!-- =================================================================== -->

	<!-- =================================================================== -->
	<!-- 1. Testing: ActionScript Mock Delegates & Services -->
	<!-- =================================================================== -->

	<object
		id="delegateLocator"
		class="com.wasi.employeeconsole.business.delegates.DelegateLocator"
		factory-method="getInstance">

		<property name="employeeDelegate">
			<object class="com.wasi.employeeconsole.business.delegates.EmployeeASDelegate" />
		</property>

	</object>

</objects>

Walking through the SASAC XML document from the top, you’ll notice the first-child node called <object>; each object tag defines a concrete object that we’ll inject into the application at run-time, as well as any properties (ie more concrete implementaitons) that we might inject into the object itself. The first object tag defines a new object that we haven’t discussed yet called the Delegate Locator (”DL”) (see Allen Manning’s Post on SAS + CGM for additional info on the DL in SAS), which is similar to the standard Service Locator (”SL”) object in CGM. However, instead of containing a registry of services like the SL, it contains a registry of BDs.

Taking a deeper look at DL object, you can see the fully qualified path to the DL object in it’s class attribute (we’ll create the AS class for the DL in the next section), and an attribute called factory-method=getInstance, indicating that it’s a Singleton. Next we’ll examine the <property> node, which is really the crux of the entire framework — here we’re setting the class property on the DL called employeeDelegate to a value of the fully qualified name of out AS mock-object delegate called EmployeeASDelegate, signifying that we’d like to inject the AS BD into the DL at run-time. Later we will setup the SASAC to inject the XML BD, but for now let’s test out this version by loading the file at run-time and making sure that it does in fact inject our AS BD.

Create the DelegateLocator

Since our DL is really just a registry of the BDs we want to use at run-time, we need to create a getter and setter method for each BD we want to inject into it with the same property name as the one we used in the SASAC — employeeDelegate. Create a new AS class called DelegateLocator and make it a singleton. Next, create a private var representing the employeDelegate with corresponding getters and setters and make sure they use our Employee Delegate interface, IEmployeeDelegate as the type:

/**
 * Reference to the employee delegate. Provides an interface
 * to get the injected delegate at run-time.
 */
private var _employeeDelegate:IEmployeeDelegate;
public function get employeeDelegate():IEmployeeDelegate
{
	return this._employeeDelegate;
}
public function set employeeDelegate(delegate:IEmployeeDelegate):void
{
	this._employeeDelegate = delegate;
}

Modify the GetEmployeeCommand to Use the DelegateLocator

If you recall, we recently modified the GetEmployeeCommand to reference the EmployeeXMLDelegate…we’ll need to go back into the CMD and modify it again to use the DL and Interface to acquire the injected BD:

private var delegate:IEmployeeDelegate;

public function GetEmployeeListCommand()
{
	trace("GetEmployeeListCommand Constructor");
	this.delegate = DelegateLocator.getInstance().employeeDelegate;
	this.delegate.responder = this;
}

Now we’re acquiring the BD from the DL with the injected, concrete implementation set up in the ApplicationContext file, but we need to make a couple small change to our BDs and Interfaces…we need a reference to the CMD as the responder. In our previous implmentation of the CMD, we passed in a reference of itself into the constructor of the BD, but now we’re going to set it as a property on the BD. Instead of making this change in ever BD, let’s make an abstract BD that each of our concrete BDs will subclass:

AbstractDelegate

package com.wasi.employeeconsole.business.delegates
{
	import mx.rpc.IResponder;

	public class AbstractDelegate
	{
		/**
		 * Constructor.
		 */
		public function AbstractDelegate()
		{
			trace("AbstractDelegate Constructor");
		}

		/**
		 * RPC Responder, used as a reference back to the command that made the request.
		 */
		private var _responder:IResponder;
		public function get responder():IResponder
		{
			return this._responder;
		}
		public function set responder(value:IResponder):void
		{
			this._responder = value;
		}

	}
}

Now go into each BD and subclass our new AbstractDelegate:

public class EmployeeASDelegate extends AbstractDelegate implements IEmployeeDelegate
public class EmployeeXMLDelegate extends AbstractDelegate implements IEmployeeDelegate

And finally go into our IEmployeeDelegate and extend a SAS CGM extention called IResponderAware that will allow/force each of our BDs to have a set repsonder(value:IResponder) method (open up the source of IResponderAware to see what it’s doing):

public interface IEmployeeDelegate extends IResponderAware

I know, I know…this is getting long, so on with it already…

Load the Spring ApplicationContext Config

Finally, open your Application file so we can load the SASAC and instantiate the DL:

Create a class property representing the application context.
Listen for the Creation Complete event of the Application and handle it with an init() method.
Create loadSpringAppContext() method and call it in the init().
In the loadSpringAppContext() method, create a new FlexXMLApplicationContext (the application context class property we defined in step 1) and pass in the URL to the SASAC file.
Create listeners for the success and failed requests for the SASAC.
Load the File.
Upon successful retrieval of the SASAC, instantiate the DL.
Test…you’ll get an error, but this is exected and requires some explanation.

/**
 * Defines the application specific context by which objects and
 * their dependencies are loaded.
 */
private var applicationContext:FlexXMLApplicationContext;

/**
 * Called when the Application component has been created.
 */
private function init():void
{
	trace("Application init");
	this.loadSpringAppContext();
}

/**
 * Initializes the applicationContext instance and adds
 * listeners for the context file loading events.
 */
private function loadSpringAppContext():void
{
	trace("Application loadSpringAppContext");

	var applicationContextURL:String;

	applicationContextURL = "../assets/springactionscript/applicationContext.xml";

	// Initializes the applicationContext instance and adds listeners for the context file loading events.
	this.applicationContext = new FlexXMLApplicationContext(applicationContextURL);
	this.applicationContext.addEventListener(Event.COMPLETE, applicationContextLoadResult);
	this.applicationContext.addEventListener(IOErrorEvent.IO_ERROR, applicationContextLoadFault);
	this.applicationContext.load();
}

/**
 * IApplicationContextLoader.applicationContextLoadResult
 * implementation which handles successful loading of the context
 * document.
 */
public function applicationContextLoadResult(event:Event):void
{
	trace("Application applicationContextLoadResult");
	this.applicationContext.getObject("delegateLocator");
}

/**
 * IApplicationContextLoader.applicationContextLoadFault
 * implementation which handles an exception when loading the context
 * document.
 */
public function applicationContextLoadFault(iOErrorEvent:IOErrorEvent):void
{
	trace("Application applicationContextLoadFault " + iOErrorEvent.text);

	// we'll go with a simple stoopid apprach for this right now and just throw an alert
	Alert.show("Spring Application Context Failed to Load", "Error");
}

An error!?! WTF mate?

Why Did We Get An Error?

[SWF] Users:brianmriley:projects:spring-hibernate:workspaces:flex3:EmployeeManagementConsole2:bin-debug:EmployeeManagementConsole2.swf - 1,235,684 bytes after decompression
CairngormFrontController Constructor
CairngormFrontController addCommands
Application init
Application loadSpringAppContext
5/8/2009 14:40:02.804 [INFO] SpringActionScript.FlexXMLApplicationContext Loading XML object definitions from [../assets/springactionscript/applicationContext.xml]
Error: A class with the name
        'com.wasi.employeeconsole.business.delegates.EmployeeASDelegate'
        could not be found.
	at as3reflect::ClassUtils$/forName()[C:\Users\Christophe\workspace\as3reflect\src\as3reflect\ClassUtils.as:89]
	at org.springextensions.actionscript.ioc.factory.support::DefaultListableObjectFactory/getObjectNamesForType()[C:\Users\Christophe\Documents\Adobe Gumbo MAX Preview\spring-actionscript\core\src\main\actionscript\org\springextensions\actionscript\ioc\factory\support\DefaultListableObjectFactory.as:87]
	at org.springextensions.actionscript.context.support::XMLApplicationContext/registerObjectPostProcessors()[C:\Users\Christophe\Documents\Adobe Gumbo MAX Preview\spring-actionscript\core\src\main\actionscript\org\springextensions\actionscript\context\support\XMLApplicationContext.as:196]
	at org.springextensions.actionscript.context.support::XMLApplicationContext/afterParse()[C:\Users\Christophe\Documents\Adobe Gumbo MAX Preview\spring-actionscript\core\src\main\actionscript\org\springextensions\actionscript\context\support\XMLApplicationContext.as:158]
	at org.springextensions.actionscript.ioc.factory.xml::XMLObjectFactory/_doParse()[C:\Users\Christophe\Documents\Adobe Gumbo MAX Preview\spring-actionscript\core\src\main\actionscript\org\springextensions\actionscript\ioc\factory\xml\XMLObjectFactory.as:341]
	at org.springextensions.actionscript.ioc.factory.xml::XMLObjectFactory/_loadNextProperties()[C:\Users\Christophe\Documents\Adobe Gumbo MAX Preview\spring-actionscript\core\src\main\actionscript\org\springextensions\actionscript\ioc\factory\xml\XMLObjectFactory.as:315]
	at org.springextensions.actionscript.ioc.factory.xml::XMLObjectFactory/_loadNextConfigLocation()[C:\Users\Christophe\Documents\Adobe Gumbo MAX Preview\spring-actionscript\core\src\main\actionscript\org\springextensions\actionscript\ioc\factory\xml\XMLObjectFactory.as:291]
	at org.springextensions.actionscript.ioc.factory.xml::XMLObjectFactory/_onLoaderComplete()[C:\Users\Christophe\Documents\Adobe Gumbo MAX Preview\spring-actionscript\core\src\main\actionscript\org\springextensions\actionscript\ioc\factory\xml\XMLObjectFactory.as:241]
	at flash.events::EventDispatcher/dispatchEventFunction()
	at flash.events::EventDispatcher/dispatchEvent()
	at flash.net::URLLoader/onComplete()

Since we’re injecting our concrete types of BDs into the application at run-time, we never explicitly told the Flex compiler to add our EmployeeASDelegate class into the SWF; thus, when we try to instantiate it the Flash Player throws an error saying the class doesn’t exist…one way to get around this is to just create a reference to it somewhere in your application, but we’re going to take a slightly different approach and add it to a property file for better organization.

ClassReferences.properties

Create a new properties file and put it directly into the src folder of your project (again, we’ll come back to cleaning this up in later posts) and create a reference to both the EmployeeASDelegate and the EmployeeXMLDelegate, since we’ll be switching back and forth between the 2 shortly.

EmployeeASDelegate  = ClassReference("com.wasi.employeeconsole.business.delegates.EmployeeASDelegate")
EmployeeXMLDelegate = ClassReference("com.wasi.employeeconsole.business.delegates.EmployeeXMLDelegate")

Now create a reference to your ClassProperties.properties file in your main Application:

[ResourceBundle("ClassReferences")]
private var springClassRefs:ResourceBundle;

Success & Last Touches

Run your application and click the “Refresh List” button and you should see the following:

Employee Mgmt Console Populated with AS Mock Objects

Open up the SASAC file and change the reference of the Employee Delegate from the AS impl to the XML impl:

<?xml version="1.0"?>
<objects xmlns              = "http://www.pranaframework.org/objects"
         xmlns:xsi          = "http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation = "http://www.pranaframework.org/objects http://www.pranaframework.org/schema/objects/prana-objects-0.5.xsd">

	<object
		id="delegateLocator"
		class="com.wasi.employeeconsole.business.delegates.DelegateLocator"
		factory-method="getInstance">

		<property name="employeeDelegate">
			<object class="com.wasi.employeeconsole.business.delegates.EmployeeXMLDelegate" />
		</property>

	</object>

</objects>

Save it, run it, and you should see the following:

Employee Management Console with XML Business Delegate

Voila! You’ve just successfully set up your first Flex + SAS + CGM application and learned how to inject 2 different types of BDs at runtime. Say tuned for episode 3 to learn how to inject the XML HTTPService in the EmployeeXMLDelegate also via SAS.

References:

Dependency Injection in Flex Applications - Part 1 - Spring ActionScript and Cairngorm - Allen Manning
IoC and the Dependency Injection Pattern in Flex - Eric Feminella
Christophe Herreman’s Blog - Christophe Herreman

Tweet This Post

17 Comments

Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Hibernate + MySQL Tutorial Part 1

Posted by brianr in cairngorm, flex, tutorial on May 1st, 2009

Introduction

Flex
Cairngorm (”CG”)
Spring ActionScript (”SAS”), formerly Prana
Tomcat (”TC”)
WebORB (”WORB”) / BlazeDS (”BDS”)
Spring, Server-side Java version
Hibernate (”HB”)
MySQL

Tutorial Goal: Flex + Cairngorm

Build a foundational Flex + Cairngorm application that provides a solid application architecture so that we can easily add new functionality in later iterations and tutorials — this will probably be a bit slow for most experienced Flex developers, so feel free to jump to Part 2 that introduces the Spring ActionScript framework (”SAS”).

Assets:

Prerequisites & Assumptions

Ability to create Flex and ActionScript classes with Flex Builder (”FB”). NOTE: I’m actually using Eclipse WTP with the Flex Builder Plugin so I can develop in both Java/J2EE and Flex projects in one IDE.
Used or understand Cairngorm’s basic flow and how it all fits together. If you haven’t, I recommend looking at the Cairngorm Diagram for some reference.
Understanding of OOP and basic Design Patterns.

What This Tutorial is Not

This particular tutorial is not focused on why I chose CG over one of the myriad other frameworks like Mate, PureMVC, Swiz, Bob’s New AS3 MVC-based Framework with some other obscure name, etc…I could have just as easily chosen PureMVC (”PMVC”), but since CG is more widely used and I want to keep things simple, we’re going with CG. Remember, this simply sets up the plumbing for later fun, so please leave the frameworks debate and why I chose CG for another time, or at least until another post where I actually want to argue the architectural issues that both frameworks possess.

Furthermore, I won’t go into great detail about CG’s complete ins and outs and/or best practices and extensions that my team at WASI currently uses in this first post…let’s just get a CG app up and running and then come back to that in a later, cleanup/best-practices post.

So without any further delay, let’s get at it.

Create a Flex Builder Project

NOTE: If you don’t feel like writing all this from scratch, just download my project.

Since this is part one in a n+ series of tuts, let’s create a new Flex project called “EmployeeManagementConsole1″. I originally created an address book application, but since I’ll be referencing Marcel Boucher’s Blog later in the series for his Flex + Hibernate (”HIB”) Employee Management Console, I’d like to be consistent…and why reinvent the wheel…thanks for the starting point bud.

Add Libraries and Dependencies

Next we’ll need to add the necessary libraries and dependencies to the project as SWCs and AS files; for now, we’ll just need:

Cairngorm 2.2.1 (non-enterprise edition) — Download the ZIP, extract it, and import the Cairngorm.swc into the libs folder of your Flex Builder project.

Create the Flex View

Again, since we want to keep this simple, we’re going to reuse the application UI from Marcel Boucher’s Blog, so we won’t spend any great amount of detail reviewing it. Create 2 Panels and put a DataGrid (”DG”) in the left one with 3 columns in with header names : Employee ID, First Name, Last Name. In the second Panel, create a Form with 2 FormItems corresponding with the First and Last Name fields we just added to the DG. Finally, below the DG put a Button with the label “Refresh List.” It should look something like this:

Employee Management Console UI

Hook Up Cairngorm & Get Some Data

First, create a ModelLocator and give it a public property of employeeList of type ArrayCollection for our DG view to bind to: CairngormModelLocator.as

/**
 * The CairngormModelLocator provides singleton access to all the
 * model/business objects in the application.
 */
[Bindable] public class CairngormModelLocator implements ModelLocator
{
	public var employeeList:ArrayCollection = new ArrayCollection();
...
}

Go ahead and create the necessary CG Event (”EVT”), Command (”CMD”), and Business Delegate (”BD”) to actually get us some data by implementing the get list of employees functionality — just make one small change to the BD — instead of calling it EmployeeDelegate, let’s call it EmployeeASDelegate, signifying that it’s returning hard-coded AS mock objects to your CMD; this will set us up to create different BDs for different data sets with SAS in the next couple tutorials. Notice the use of trace() statements as a primitive form of logging for this first iteration; again, we’ll add in real logging in a later tutorial. Your EVT, CMD, and BD should all look something like the following:

EmployeeEvent.as

package com.wasi.employeeconsole.events
{
	import com.adobe.cairngorm.control.CairngormEvent;

	public class EmployeeEvent extends CairngormEvent
	{
		/**
		 * The event type for getting all the employees.
		 */
		public static const GET_LIST:String = "getList";

		/**
		 * Constructor.
		 *
		 * @param type The event type for the event.
		 */
		public function EmployeeEvent(type:String)
		{
			super(type, false, false);
			trace("EmployeeEvent Constructor");
		}

	}
}

EmployeeCommand.as

package com.wasi.employeeconsole.commands
{
	import com.adobe.cairngorm.commands.ICommand;
	import com.adobe.cairngorm.control.CairngormEvent;
	import com.wasi.employeeconsole.business.delegates.EmployeeASDelegate;

	import mx.rpc.IResponder;

	public class GetEmployeeListCommand implements ICommand, IResponder
	{
		private var delegate:EmployeeASDelegate;

		public function GetEmployeeListCommand()
		{
			trace("GetEmployeeListCommand Consturctor");
			this.delegate = new EmployeeASDelegate(this);
		}

		public function execute(event:CairngormEvent):void
		{
			trace("GetEmployeeListCommand execute");
			this.delegate.getList();
		}

		public function result(data:Object):void
		{
			trace("GetEmployeeListCommand result");
		}

		public function fault(info:Object):void
		{
			trace("GetEmployeeListCommand fault");
		}

	}
}

EmployeeASDelegate.as

package com.wasi.employeeconsole.business.delegates
{
	import flash.utils.setTimeout;

	import mx.collections.ArrayCollection;
	import mx.rpc.IResponder;
	import mx.rpc.events.FaultEvent;
	import mx.rpc.events.ResultEvent;

	/**
	 * A hard-coded delegate that creates mock objects and sends them back
	 * to the correspnding command as if it had actually called a real asynchronous
	 * service.
	 */
	public class EmployeeASDelegate
	{
		/**
		 * RPC Responder, used as a reference back to the command that made the request.
		 */
		private var responder:IResponder;

		/**
		 * Constructor.
		 */
		public function EmployeeASDelegate(responder:IResponder=null)
		{
			trace("EmployeeASDelegate Consturctor");
			this.responder = responder;
		}

		/**
		 * Get the list of employees.
		 */
		public function getList():void
		{
			trace("EmployeeASDelegate getList");

			// we'll fake an asynchronous service call with a slight delay
			setTimeout(result, 1000, new ResultEvent(ResultEvent.RESULT));
		}

		/**
		 * Handles the successful service request.
		 *
		 * @param response Object The success event coming back from the asynchronous
		 * service call containing the data payload.
		 */
		public function result(resultEvent:ResultEvent):void
		{
			trace("EmployeeASDelegate result");

			var response:ArrayCollection;

			response = new ArrayCollection();

			// pass the command the response object to do whatever it wants with it
			this.responder.result(response);
		}

		/**
		 * Handle the failed request. Pass it on
		 * to the command that originally requested it.
		 *
		 * @param faultEvent The fault event coming back from the asynchronous
		 * service call containing the error message, etc.
		 */
		public function fault(faultEvent:FaultEvent):void
		{
			trace("EmployeeASDelegate fault");

			this.responder.fault(faultEvent);
		}

	}
}

Don’t forget to add the EVT to CMD mapping in the FrontController (”FC”):

CairngormFrontController.as

/**
 * Map all the events to commands.
 */
protected function addCommands():void
{
	trace("CairngormFrontController addCommands");

	this.addCommand(EmployeeEvent.GET_LIST, GetEmployeeListCommand);
}

After creating the plumbing with our CG classes, let’s add in a click handler method for the “Refresh List” button called “getList()” and implement it by calling the CG EmployeeEvent:

EmployeeManagementConsole1.MXML

private function getList(event:MouseEvent):void
{
	trace("Application getList");

	new EmployeeEvent(EmployeeEvent.GET_LIST).dispatch();
}
...
<mx:Button label="Refresh List" click="getList(event)"/>

Flex Builder Console

Test the application in Debug Mode and you should see something like the following in the Flex Builder console:

[SWF] Users:brianmriley:projects:spring-hibernate:workspaces:flex3:EmployeeManagementConsole1:bin-debug:EmployeeManagementConsole1.swf - 1,073,390 bytes after decompression
CairngormFrontController Constructor
CairngormFrontController addCommands
Application getList
EmployeeEvent Constructor
GetEmployeeListCommand Constructor
EmployeeASDelegate Constructor
GetEmployeeListCommand execute
EmployeeASDelegate getList
EmployeeASDelegate result
GetEmployeeListCommand result

Now that we know our CG application flow hooked up, let’s add some data and populate our list of employees DG in the view. We’ll start by creating a simple client-side representation of an Employee object, sometimes referred to as a model, domain, business, or value object. Since we’ll ultimately map this Employee AS object to a Java object, we’ll place it in the client-side model package. Give it three public properties: id, firstName, lastName:

EmployeeModel.as

package com.wasi.employeeconsole.models
{
	public class EmployeeModel
	{
		public var id:int;
		public var firstName:String;
		public var lastName:String;
	}
}

EmployeeASDelegate#result(resultEvent:ResultEvent)

Next we’ll use this object to create a list of employees in our mock-object AS BD — open up EmployeeASDelegate and create an ArrayCollection (”AC”) of Employee objects in it’s result() method like so:

public function result(resultEvent:ResultEvent):void
{
	trace("EmployeeASDelegate result");

	var response:ArrayCollection;
	var employee:EmployeeModel;

	response = new ArrayCollection();

	employee = new EmployeeModel();
	employee.id = 0;
	employee.firstName = "Brian";
	employee.lastName = "Riley";
	response.addItem(employee);

	employee = new EmployeeModel();
	employee.id = 1;
	employee.firstName = "Tim";
	employee.lastName = "McGee";
	response.addItem(employee);

	employee = new EmployeeModel();
	employee.id = 2;
	employee.firstName = "Joe";
	employee.lastName = "Seiter";
	response.addItem(employee);

	// pass the command the response object to do whatever it wants with it
	this.responder.result(response);
}

GetEmployeeListCommand#result(data:Object)

Once our BD creates the data, it’ll pass it back to the CMD to actually set the data on the model, so we’ll need to make some modifications to the result() method in GetEmployeeListCommand:

public function result(data:Object):void
{
	trace("GetEmployeeListCommand result");

	var employeeList:ArrayCollection;

	employeeList = data as ArrayCollection;

	CairngormModelLocator.getInstance().employeeList = employeeList;
}

Bind Employee DG View to Model

Finally, let’s bind the DG to the list of employees in the model by means of MXML data binding:

<mx:DataGrid
	id="dgrid"
	dataProvider="{CairngormModelLocator.getInstance().employeeList}"
	width="100%" height="411"
	bottom="0" right="0">

	<mx:columns>
		<mx:DataGridColumn headerText="Employee ID" dataField="id"/>
		<mx:DataGridColumn headerText="First Name" dataField="firstName"/>
		<mx:DataGridColumn headerText="Last Name" dataField="lastName"/>
	</mx:columns>

</mx:DataGrid>

When you test your application, you should see something like:

Employee Mgmt Console Populated with AS Mock Objects

At this point we have a basic Flex + CG app up and running…exciting, nah, not really. But we do have the bare-bones code base we’ll need to start having some real fun. Next, learn what SAS is and how to integrate it into this basic CG application.

Part 2: Flex + CG + SAS

References:

My First Hibernate Enabled Flex Application - Marcel Boucher

Tweet This Post

cairngorm, flex, tutorial

7 Comments

Web App Solution Blog

Archive for category tutorial

Swiz Passive View Example :: Part 2

Swiz Passive View Example :: Part 1

Axiis Drill Down Example

Axiis Examples with Lots of Comments

Flex + Cairngorm + Spring ActionScript Part 5 Announcement

Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Hibernate + MySQL Tutorial Part 4

Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Hibernate + MySQL Tutorial Part 3

Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Hibernate + MySQL Tutorial Part 2

Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Hibernate + MySQL Tutorial Part 1

Archives

Meta