Each mediator or proxy needs a unique ID. One way to accomplish this is to pass a unique identifier in the mediator/proxy's constructor:

:

public static const NAME:String = "MyUniqueMediator";
private var aValueObject:MyVO;

public function MyUniqueMediator(viewComponent:Object, aValueObject:MyVO)
{
        this.aValueObject = aValueObject;
        super(this.getMediatorName, viewComponent)

}

override function getMediatorName():String
{
        return NAME+aValueObject.uniqueProperty;
}
now you can access it with :

:

var mediator:MyUniqueMediator = facade.retrieveMediator(MyUniqueMediator.NAME+aValueObject.uniqueProperty as MyUniqueMediator;
This works the same for proxies.

Actually we are using Pure MVC instead of cairngorm. But we are not sure about the charges.Is this open source or will they charge any if we use in production environment.

There is no charge associated with using, distributing, or modifying the PureMVC framework. If you distribute the source, the only restriction is that the license headers in the framework source files remain intact.

Here's the relevant FAQ entries.

Hi,

We are planning to use Cairngorm in our project.From the sites we understood that it is open source framework.Do we get any issues regarding license or any charges if we use these for deployment in production environment.

Thanks,
Aparajitha

You should probably take this up with Adobe.

I think you should consider PureMVC over Cairngorm. It brings more joy.

I've personally been trying to get into the habit of using my mediators more for this type of functionality. Usually I will build the component, do as you have done, and then pull it out into the appropriate mediators to leave the viewComponents as light as possible.

There is nothing wrong with what you are doing though, the viewComponents are still oblivious to the framework and just going about their business. I'd probably keep the listOfThumbnails on a proxy myself, but that too wouldn't be strictly necessary.

Just out of curiosity, why does your mediator access facade as _facade?

No, proxies don't receive notifications. You are communicating directly with your proxy by grabbing its instance and calling methods on it. onTryLogin is sending a Notification which should be retrieved by a Command, which in turn will access the proxy in the same fashion. You could substitute this in the onTryLogin method:

:

               var loginProxy:AccessProxy = facade.retrieveProxy(AccessProxy.NAME) as AccessProxy;
               loginProxy.login(accessPanel.loginVO);
You have a circular reference going here, and AccessProxy.LOGIN is probably not needed at all. Instead you would just have:

:

      override public function handleNotification(notification:INotification):void
      {
         switch(notification.getName()) {
            case AccessProxy.LOGIN_SUCCESS:
               mx.controls.Alert.show("access granted");
               break;
            case AccessProxy.LOGIN_FAILED:
               mx.controls.Alert.show("access denied");
               break;
         }
      }   

What is needed is a diagnostic utility that can be used to log regisrations and removals and provide a view component showing all the commands, mediators and proxies that are registered for which notifications at any given moment. The trick would be to have an 'intercepting Facade', which overrides all the registration and removal methods of the framework facade and before calling super, caches what actor and notification is being registered or removed. The view component that displays this info would need to be hooked to the data being collected in an out-of-band way that doesn't use the notification system so as not to affect it, if possible.

I've been meaning to write this for a whils but haven't had time. If someone would like to be a hero and do so it'll be appreciated. Otherwise, eventually I'll get to it...

-=Cliff> 

I put something together. It is completely flexCentric. You have to extend your ApplicationFacade with NoteTrackerFacade and there is a viewcomponent to put someplace. The class that monitors registrations is a singleton, so you can grab it with NotificationRegistrar.getInstance() and its notificationMap property is where the command and mediator notification interests are stored. I made it to fit into a tree view, so it uses some of those flexy structures to fit into that dataProvider model.

I banged it out pretty quick, so I don't know if it will be that useful. I'm happy to enhance it if it is worth pursuing.

Just so we're 100% clear on this...  I am permitted to write a piece of software with PureMVC at its core and resell the software for profit?

Man... I hope so, otherwise I'm hatin it.

Cliff has stated on many occasions that you can do whatever you want with PureMVC as long as distributed source retains it's copyright headers. I'm sure you'd prefer to hear it from him, but that is the deal.

I do it in my ApplicationMediator or via commands. For my system tray menus, I will usually tie them into commands for interaction, and change things like bouncing or icon changes in the ApplicationMediator. I would say you definitely don't want to put this in the MXML. Not that you couldn't, it just fits nicely in a mediator. In addition, I will often mediate the menus for system items (tray and window) because their mediators can get a bit large and clutter up the ApplicationMediator.

http://code.google.com/p/as3notificationlib/

I don't know if you are using this, but it is pretty freakin sweet. He has a number of other libraries posted too.

I use Komodo for Python, it provides a lot of nice code completion, but ya, contextually speaking it is a big jump from python to actionscript.

They play really well together though. I tried to get into Java for my service tier, but I am back to Python. It is such a pleasant language to use :>

is there a need for custom events when we can pass Array as notification body.

I think you can almost ALWAYS toss around generic objects ( [], {}, etc ). It will probably save you a few minutes up front, but why not create the VOs and have type safe messages being tossed around that are clearly defined against a documented interface (yay code completion!)?

In my simple chat application I am using a database, so it is a little different, but I keep a ChatSessionVO and ChatMessageVO going so that I can have nice logs and offline messaging and whatnot.

You can of course extend Notification or write new INotification classes.

The advantage to me is that I can push around notifications with the convenient sendNotification method. I also don't have to create 40 or 50 different Notification classes to cover the entire model. It is nice to know that I could if necessary though.

I type check my notification bodies on the receiver side and throw an Error if it is wrong. Not as convenient as compile time type checking, but it is effective.

I put it in a command. I generally use windows as wrappers only (with the idea that maybe this will one day want to be a web app), but since I also want to pop the windows from multiple locations, the command works very well. Generally something like this:

:

public class MyWindowOpenCommand extends SimpleCommand implements ICommand
{
override public function execute(notification:INotification):void
{
var myWindow:MyWindowWindow;
var myWindowMediator:MyWindowMediator;
if( ! facade.hasMediator( MyWindowMediator.NAME ) )
{
myWindow = new MyWindowWindow( )
myWindowMediator = new MyWindowMediator( myWindow )
facade.registerMediator( myWindowMediator );
myWindow.open();
myWindow.nativeWindow.x = (Screen.mainScreen.bounds.width - myWindow.nativeWindow.width) / 2;
myWindow.nativeWindow.y = (Screen.mainScreen.bounds.height - myWindow.nativeWindow.height) / 2;
}
else
{
myWindow = MyWindowWindow( facade.retrieveMediator( MyWindowMediator.NAME ).getViewComponent() )
myWindow.activate()
myWindow.orderToFront();
myWindow.nativeWindow.notifyUser( NotificationType.INFORMATIONAL );
}
}
}

I use the main window for my splash screen and then hide it later. I turn off all the chrome and center it to the main screen. I then pop new windows for my other views because I generally want chrome on them.

the constructor for CarDetailsMediator:

:

private var car:Car;

public function CarDetailsMediator(viewComponent:CarDetails, car:Car)
{
     this.car = car;
     super(NAME,viewComponent)
}
Then you can shove it into the view however you like.

favour composition over inheritance

Is it just me, or is this one of the most cherry picked statements ever?

From the book:

Favor object composition over class inheritance

Ideally, you shouldn't have to create new components to achieve reuse. You should be able to get all the functionality you need just by assembling existing components through object composition. But this is rarely the case, because a set of available components is never quite rich enough in practice. Reuse by inheritance makes it easier to make new components that can be composed with old ones. Inheritance and object composition thus work together.

[emphasis mine]

favor is not code for dogmatic implementation of a single option.