The day I read about Flex Code Generator (FCG) with PureMVC support it seemed as though all the hassle of setting up a new project would be taken care of with the click of a button. Turns out it might not be as great as I'd hoped.

Upon opening FCG, you're given the choice of what type of project to create: Flex, Flex + Cairngorm, Flex + PureMVC, or PHP. I have only tested for PureMVC since that's our framework of choice. It generates 4 files to start: ApplicationFacade.as, MainView.mxml, MainProxy.as, and StartUpCommand.as in a package structure with model, view, and control folders. My main gripe with these pre-generated files is that they are not editable. When they are generated you can preview the text in them; however, you cannot change any of it. Plus I would like to be able to choose the name of my view component instead of defaulting to MainView.mxml, not to mention it extends Canvas instead of Application. Also, while these are mostly necessary files, I'd like to choose whether I need a MainProxy or not. You can delete unnecessary files but the package structure for it remains. And where is the ApplicationMediator?

Along with these auto-generated files are a series of options to create an Event, Singleton, Mediator, Proxy, or to import a Value Object or Service. Somewhere along the line creating a command got left out.

Creating an Event:
When creating an event you can choose from a CairngormEvent, Event, or a custom type. FCG allows you one variable to add to the event, which you get to choose only the type. For example, if you want to make a var that is a String you get a variable called string:String, no fancy names here. This is mainly ok, variables are easily renamed. The only potential problem I see with the generation of the Event class is that FCG puts the variable in the constructor.

Creating a Singleton:
This couldn't be more straightforward. You name the class and it gives you a perfect Singleton class. You add the rest. This is probably the best and easiest part of FCG.

Creating a Mediator:
You choose the class name, FCG adds 'Mediator' to it. Also it names the viewComponent the same as the class name.
The nice part about the pre-generated mediator is that it takes care of the listNotificationInterests and handleNotification methods for you. By default all mediators are static with a static name, though this is easily fixed through manual editing.

Creating a Proxy:
Pretty straightforward, again you choose the class name and FCG adds 'Proxy' to it. That's about it other than making the class bindable and static, which again is easily fixable through manual editing.

Importing a Service:
Select a Java, PHP, or C# file to import and input your endPoint and destination and FCG will generate RemoteObject and Responder objects, then include a service call for each method in your service that you choose to import. Fairly useful if you're into RemoteObjects.

Importing a Value Object:
This is a bit touchy, it only works occasionally for me. FCG asks you to import a Java, PHP, or C# file but more often than not it doesn't register anything in the file. Once you find a file that works, get ready for a load of new files. FCG generates the VO with optional getters/setters for each var, and a Proxy in which it includes an arrayCollection and a reference to the VO. Optionally you can generate an Event class that will include GET, GET_ALL, CREATE, UPDATE, DELETE, and SELECT events, as well as two view components, a form and a list, and their corresponding Mediators.
This is where it gets a bit confusing. For the list view it generates a list with a create and a delete button, and a mediator that listens for an item added, deleted, or selected from the list. For the form it is a textInput with a save button that will rename the selected item in the list. Although I can see the use of creating a view and its corresponding Mediator, the addition of ui components to the view class is a bit unnecessary.

The biggest change that would make me more likely to use FCG would be the ability to edit the text in the generated classes before publishing. Overall, I would recommend FCG for creating instances of certain files that are annoying to create over and over, but not an entire setup. FCG's most convenient feature is that it allows you to publish only selected files from the generated project as opposed to the entire set. Any one out there saving time with FCG?

So a while ago we promised to discuss the capabilities of PureMVC mediators and proxies in creating reusable components. But this week an update to the framework makes it easier than ever to use dynamic naming conventions.

Our main beef with the mediators in the last post was that it was inconvenient to name them dynamically as we had to come up with a workaround similar to what was implemented in the proxies.
For any of you not familiar, proxies and mediators are retrieved by name, making it necessary to have unique names for each mediator. The Proxy class lets you supply a unique name:

The Mediator class previously lacked this same naming solution so we had to come up with our own similar way of assigning it:

But now has been updated to include a name as a parameter in the constructor, rendering our solution unneeded. So how does this affect our reusable components you say? Well, we have realized that creating and displaying multiple instances of the same component on screen at the same time requires a little finesse.

First of all, we had to take advantage of using the dynamic names for both mediators and proxies for our component. We based their names on the uid of the viewComponent.
So for example, we often have viewComponents whose uid is something along the lines of Canvas10.ModuleLoader33.Module85, therefore our mediator would be named
Canvas10.ModuleLoader33.Module85Mediator and our proxy would be named Canvas10.ModuleLoader33.Module85Proxy.
This leads to being able to retrieve the mediator and proxy from anywhere that has access to the viewComponent by simply using the following:

Once the mediator and proxy were both established for the component, we thought all was smooth sailing. Until we started listening to notifications and realized that every copy of the component received them no matter which one requested the action.
In other words, component1, component2, and component3 are all of type OurCustomComponent. Component1 calls a method in the proxy and listens for a notification back that it is finished loading data.
Component1 receives the notification, but so do component2 and component3 that also have the notification listed in listNotificationInterests. So how to tell the difference when receiving notifications?

Simple, we used the type property on each notification. We set the type to the mediatorName that was passed from the mediator to the proxy.

Then the proxy made calls to the service to save data and when it finished, it returned the mediatorName as the type in the notification.

Then when the mediator gets the notification back in handleNotification, we check to see if the type matches the name of the mediator. If it does, the notification is meant to be received by this instance of the mediator, if not it is discarded.

This example will create a component that is on stage at application startup.

To start, create a new flex project and call it PMVC_Example, then add PureMVC.swc to project->properties->build path->library path of flex project.

(you can check out the PMVC_Example source through SVN for more details and to follow along).

you will need to create the following files but do not worry about populating them yet:

1. application mxml file will be created by default (PMVC_Example.mxml)
2. create ApplicationFacade class that extends Facade and implements IFacade
3. create a StartupCommand class that extends SimpleCommand and implements ICommand, you will be specifying this to run at startup
4. create classes specific to the view component:
   1. create mxml view component with visual layout (put a button or something simple in it) - MyView.mxml
   2. create proxy class that extends Proxy and implements IProxy if component needs data (optional)- MyProxy.as
   3. create mediator class that extends Mediator and implements IMediator (pre-generated methods in mediator other than the constructor and proxy can be removed.) - MyMediator.as

add the following to the already created classes:

ApplicationFacade

1. define a notification string to be the name of a startup notification

   [Copy to clipboard][-] View CodeACTIONSCRIPT

   public static const STARTUP:String = "STARTUP";

2. also override public function initializeController() and register your first command so that it will execute when a startup notification is sent

[Copy to clipboard][-] View CodeACTIONSCRIPT

registerCommand(STARTUP, StartupCommand);

3. be sure to remember to call super().initializeController() here!
4. (can remove all pre-generated functions from this class that were added by IFacade)

Application.mxml

1. add view component to stage and give it an id called testComponent
   1. this will be used in the command to register the view components mediator and proxy
2. create public var facade:ApplicationFacade
3. add a listener for creationComplete and have it call an init method
4. in init method instantiate facade

   [Copy to clipboard][-] View CodeACTIONSCRIPT

   facade = ApplicationFacade.getInstance()

5. and send startup notification

   [Copy to clipboard][-] View CodeACTIONSCRIPT

   facade.notifyObservers(new Notification(ApplicationFacade.STARTUP, this))

6. first argument is notification name, second is notification body. we will use body to access view components on stage when we register mediators and proxies
7. this notification will trigger StartupCommand to execute

StartupCommand

register mediator and proxy with references to the view component they pertain to (proxy first)

• execute() will receive reference to INotification, we are interested in the body of the notification

[Copy to clipboard][-] View CodeACTIONSCRIPT

var app:PMVC_Example = notification.getBody() as PMVC_Example; facade.registerProxy(new MyProxy()); facade.registerMediator(new MyMediator(app.testComponent));

How to Add Interactivity to Your Basic PureMVC Component

Currently you should have on screen one basic view component, which has a registered mediator and proxy. There is nothing happening beyond this. How do I make cool shit happen?

Let's go for this: Put a Button and a Text component into your mxml view component. Clicking the button will change the text field.

1. in the view, create and dispatch an event that happens when you click the button
2. in the mediator listen to the view for this event, when it fires it will call a method on the mediator
3. from the mediator, change the text of the text field

Yes I realize this is not cool. But it demonstrates where you should be doing things that alter your view. All logic goes in the mediator, not the view itself!

Coming Soon: how to add interactivity between multiple components.

The best part about new projects is getting to try out all the latest software and ideas on a clean slate. You’ve spent months finishing up that last project, reading blogs and forums, keeping up to date and brainstorming what you want to incorporate into the next new project you start.

Same goes for us at 9mmedia. As our latest project was brought to the table, we immediately tossed out new ideas about what would make this one faster to load, better designed, more compatible with all systems. But a big chunk of our concern was put toward how to make it easier to develop and collaborate, so we looked into frameworks and ultimately decided on PureMVC. Compared to Cairngorm, ServerBox, and a few others, we felt it best fit our needs. Plus it was ranked most approachable, flexible and scalable by developers at the Silicon Valley Flex Users Group (SilvaFUG), held at Adobe's offices in San Francisco recently.

I went into PureMVC expecting the standard model, view, and controller classes, but instead found myself face to face with proxies, mediators, commands, and façades. Just a swap in terminology? Not quite. PureMVC provides the model, view, and controller just as expected but hides them behind a global façade layer with mediators and proxies to manipulate them.
The façade class allows a single point of access to data and view objects from anywhere. The façade delegates actions to the model, view, and controller classes as appropriate, enforcing the MVC design pattern. And though a bit confusing at first, it ensures the proper data and event handling so new developers who aren’t familiar with the MVC design pattern can easily get into the flow of it.

The mediators act as intermediates between the view and its data, which is held in a proxy. This helps simplify the view and leaves it to hold just the GUI, with the mediator containing any code that is needed to alter data or do any communication with the rest of the application.

The other convenient thing PureMVC offers is notifications. Similar to events but a little more globally used, notifications implement an observer pattern that allows any object to register itself to the notification. Mediators list which notifications they are interested in receiving and no matter where they are sent from, the mediator will receive them.

The biggest downfall so far is the fact that the mediators and proxies are expected to be singletons. This makes reusable components with unique datasets impossible because they would each be accessing the same proxy with the same data through the same mediator. The mediators and proxies should be dynamic so that each view can have its own instance of each, and in an upcoming post I will be sharing some ways to make these changes within the framework.

9mmedia's new years resolution was to start up the blog. I would say "bring back the blog" but I have to admit we never really got it going. We have been very busy the last few years, and now its time to start writing about our travels through the land of flash, flex and java. Our time has been spent building flex applications, both public facing and enterprise b2b. Both use lots of custom components, skinning, real-time collaboration and are built on top of LCDS (Adobe LiveCycle Services).

We have decided we wanted to share some the interesting things we have been doing. We have starting playing with the Pure MVC framework, been wrestling with LCDS(messaging, assemblers), learning the ins and out of Flex Builder, creating an Adobe AIR app, and lots more. So stay tuned for some meaty posts, and feel free to comment if you have topics you would like to hear about.