PureMVC uses mediators for all communication from the model and controller to the view. Out of the box PureMVC normally creates the view mediators after creationComplete has fired and the model has been initialized. The reason for this is that mediators require a reference to a view component to work. In order to construct a mediator you first need an object or view component to pass to the constructor.

There are basically three different ways to handle this, two of which I don’t recommend using.

1. Use dummy objects to initialize mediators
If you know that your view component is not on the stage yet you could still create it’s mediator by passing a POASO (plain old actionscript object) to it’s constructor. I have two problems with this solution; One you’re unnecessarily using memory and two you have not treated the whole problem, you still need some type of event schema to reinitialize the mediator once the component has been created. I don’t recommend using this solution.

2. Use creationPolicy=”all” to avoid deferred views
By default components like ViewStack and TabNavigator on create their top level children at runtime. The remainder are created as the user navigates to them. You can use the creationPolicy=”all” attribute to override this behavior. This causes the application to create all the view components at runtime. This is a terrible idea and I cannot recommend it. What you are in effect saying to your user is “I don’t care about your memory or performance because I’m to lazy to code a decent solution” I know this is a bit dramatic but I hate when people use this attribute.

3. Use a custom Event subclass
The idea here is to create an event subclass that the application mediator or another mediator can listen for and use to create new mediators. This event class has an extra property which holds a reference to the newly created component, other mediators can use this reference to construct a mediator for the component. This approach not only keeps your memory footprint smaller but it allows you to easily create and destroy mediators. Here’s an example of an Event subclass:

You create your own constant names based on the event type you want your mediator to listen for.

[as]
package com.tomcornilliac.myproject.events
{
import flash.events.Event;

public class ComponentCreationEvent extends Event
{
// Publically accessible properties
public var component:Object;

//Constants used for routing withing PureMVC mediators
public static const SOME_EVENT:String = “gatewayCreated”;
public static const SOME_OTHER_EVENT:String = “gatewayStackCreated”;

public function ComponentCreationEvent(type:String, component:Object, bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
//Probably should have a getter/setter for this property
this.component = component;
}

//You must override the clone method
override public function clone():Event
{
return new ComponentCreationEvent(type, component, bubbles, cancelable);
}
}
}
[/as]

An instance of this event is dispatched from your view component with a reference to its self. Note that “bubbles” is set to true, this is required for the event to make it up the chain to whatever mediator is listening.
[xml]

width="100%" height="100%" creationComplete="init(event)">

[Event(name="gatewayCreated", type="org.deschutes.grizzly.events.ComponentCreationEvent")]

import com.tomcornilliac.myproject.events.ComponentCreationEvent;

private function init(e:Event):void
{
dispatchEvent(new ComponentCreationEvent(ComponentCreationEvent.GATEWAY_CREATED, this, true));
}
]]>

[/xml]

The listening mediator (in this case the ApplictionMediator) will respond to the event and create and register a new mediator for the newly created view component. Now it’s important to note that while I’m using the ApplicationMediator in this example, you can use any mediator you want, so long as the event will bubble-up to it.

[as]
package com.tomcornilliac.myproject.view
{
import com.tomcornilliac.myproject.events.ComponentCreationEvent;
import com.tomcornilliac.myproject.view.components.SomeComponent;
import org.puremvc.interfaces.IMediator;
import org.puremvc.interfaces.INotification;
import org.puremvc.patterns.mediator.Mediator;

public class ApplicationMediator extends Mediator implements IMediator
{
//Canonical name of the mediator
public static const NAME:String = ‘ApplicationMediator’;

//Constructor
public function ApplicationMediator(viewComponent:Object)
{
super(viewComponent);

/**
* Setup event listeners for components created dynamically
*/
app.addEventListener(ComponentCreationEvent.SOME_EVENT, createNewMediator);
}

private function createNewMediator(e:ComponentCreationEvent):void
{
//Create the new Mediator and initialize it with the component from our event
var mediator:SomeComponentMediator = new SomeComponentMediator(e.component);
//Register the mediator with the Application Facade
facade.registerMediator(mediator)
//That’s it now your view component is hooked-up and ready to handle I/O
}

….other methods
[/as]

This technique is not only good for component creation but you could just as easily create a custom ComponentDestructionEvent and use it to remove Mediators off the stack when no longer needed.

If you would like more information about the PureMVC framework I encourage you to visit the PureMVC web site. The documentation is excellent and there’s even a training course to help you on your way.

Yesterday while researching the depths of Flex CSS I discovered you can apply Flash Filters to Flex Components. That’s what I want to explore in this post. Flash filters can not only make your application look better but they can also improve the user experience. You could us the Glow filter to provide user feedback based on mouse movements or you might use Blur filter to direct the user’s attention to an object on screen (similar to a modal Title Window but with more options). The flash.filters package contains 13 filters you can use and combine to create some amazing styles without having to resort to skinning.

There are two methods for implementing Flash Filters in your Flex application.

1. You can create a new namespace linked to the flash.filters.* package, just like you would a Flex Component.
2. You can apply filters through ActionScript

Both of these approaches have their own benefits and it’s really up to the developer/designer as to which method to use. Let’s look at the basic syntax of each method.

<mx:Application>
    xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns="*"
    xmlns:flashFilter="flash.filters.*"&gt;

<mx:TextArea>
    width="150" height="100"
    cornerRadius="6" text="Some text"&gt;
         <mx:filters>
             <flashFilter:DropShadowFilter>
                 inner="true" distance="3"
                 angle="120" color="0x000000"
                 alpha="0.4" /&gt;
            </flashFilter:DropShadowFilter>
        </mx:filters>
</mx:TextArea>

</mx:Application>

import flash.filters.*;

private function addGlow(event:MouseEvent):void
{
    var g:GlowFilter = new GlowFilter(0x006666, 0.65, 15, 15);
    var newFilters:Array = new Array();
    newFilters.push(g);
    event.currentTarget.filters = newFilters;
}

As you can see Flash Filters are easy to implement and you don’t need any other software.

Flash Filters Demonstrated

I’ve created a very small Flex app to demonstrate both of these techniques as well as give you something to look at. View Source is enabled so right + click and select view source to download the app and view the full source.

Other Resources

• Adobe Consulting
• Flex Themes at scalenine.com
• Using Filters in Flex (livedocs)