document.getElementById('addRoleButton').onclick = Relegate.create(this,this.__onAdd);

Which is not the right place in the PureMVC philosophy to bind event listeners.

This code is located in a view. Views are independent from the PureMVC framework. Here, RolePanel is not a dom element but a Javascript pseudo-class made to wrap the DOM element on which we cannot directly rely to dispatchEvent (not on all browsers...). Look at it as a Javascript "code behind". It looks like a mediator, but it's just a Javascript UI component.

I will have preferred not to depends on our own EventDispatcher class, but we need it for complete compatibility. I've started to build a JQuery example to show how to use the PureMVC framework with JQuery. With JQuery, or any another JS framework, I'm sure you can rely on customs EventDispatcher not to have to depends on a view helper as in the Employee Admin example.

In JS you should rather use something like :
document.getElementById('addRoleButton').onclick = sendEvent( ADD );

We sadly cannot do this either, as you need at least to declare your sendEvent method declaration. You need some code behind, so you need this RolePanel.js component. Look at RolePanel.mxml in the PureMVC AS3 Employee Admin demo you will understand that RolePanel.js is its equivalent.

If you find a better solution with a Javascript framework dedicated to UI let us know.

It seems exactly what many of us are waiting for a long time. I'm excited to see what you've done. And no, I will not ask when will we have it as a demo here.

Oh sorry, I didn't see that the question was relative to Fabrication. I follow threads linearly with my RSS reader. I believe you where talking about the PureMVC framework.

We cannot handle notification with respondTo**** natively. It is your responsibility to handle the notification in handleNotification and to redirect to your method respondTo**** next. So, to be precise, it is a mandatory to use both in your case. 

Philippe one of the author of the FlashDevelop project give me this url : http://gurufaction.blogspot.com/2007/07/puremvc-project-template-for.html

Hope this helps.

It's not an automatic mechanism, you have to register mediators in a command or in mediators itself as Cliff explains it in the previous post. Mediators of the EmployeeAdmin demo are registered within the StartupCommand :

:

    public class StartupCommand extends SimpleCommand implements ICommand
    {
        /**
         * Register the Proxies and Mediators.
         *
         * Get the View Components for the Mediators from the app,
         * which passed a reference to itself on the notification.
         */
        override public function execute( note:INotification ) : void   
        {
            facade.registerProxy( new UserProxy() );
            facade.registerProxy( new RoleProxy() );
           
            var app:EmployeeAdmin = note.getBody() as EmployeeAdmin;
            facade.registerMediator( new UserFormMediator( app.userForm ) );
            facade.registerMediator( new UserListMediator( app.userList ) );
            facade.registerMediator( new RolePanelMediator( app.rolePanel ) );
        }
    }

I do not know what Cliff will say, but now your request seems fair to me. Sorry not to have understood immediately. 

@willw You're right, you must understand *commandComplete* not *onComplete*.

To be honnest, I can't see the context where you need an AsynCommand to call *commandComplete* without to have a wrapper that declare the *onComplete* callback like in the AsynMacroCommand. But you're right, your patch will prevent any use of the AsyncCommand as a SimpleCommand.

Willw, it's up to you to call the onComplete handler from a standalone AsyncCommand instance.

Look at the comment :

* Call this method from your subclass to signify that your asynchronous command
* has finished.

So it's not a bug. The class do not know the logic that drive to the end of the execution of the asynchronous process, the instance have to call *onComplete* itself to notify of the end of the asynccommand execution.

1>Why not let users to register multiple proxies of the same class with different names, and decouple this view-specific logic from the proxies themselves?

It is the Proxy default behavior. Look at the Proxy class constructor default arguments : (proxyName:String=null, data:Object=null). It's only a convention to use a constant as proxy name when you did not need to create multiple proxies of the same class in your application.

2>Why should proxies be required to expose their data object?

Not sure here, but I think it's a good practice to give access to the data when the proxy's data is a VO. You can use it as *protected* or *private* to give the data the good type in the Proxy itself. I found it useful in UnitTests to verify from the Test that the proxy acts as expected on the data.

I was talking about UserVo directly because it uses DataBinding. But if you really need to think with a list, you'd better look at RoleVO in the same project. The RoleVO object is Bindable, it uses a Proxy and an ArrayCollection to store the user roles. So when a role is selected or added, the RolePanel reflect the changes immediately without any notification involved in the process. Look at RolePanel roleList List component you'll see what I'm talking about

The model inform the view that data is updated without to have to know any view concrete class, it respects MVC. But you loose control on the notification and will not be able to filter which component must reflect changes or not. You'd better use a notification for that.

If you do not want to use a PureMVC notification, you can use DataBinding. Look at the EmployeeAdmin demo UserVO to understand what I mean. The way it works is the same, but it automatizes the way it creates the notification. My advice is to use a notification.

If you wish to only have the result of the getSomeData() result be taken into account by the mediator that emits the request, you can put a flag property on all interested mediators named for example useImmediatlyNewCountryList:Boolean = false and use something like :

:

{
useImmediatlyNewCountryList = true;
retrieveProxy("YourProxyName").getSomeData()
}

and in the method in charge to receive the notification of a new country list arrived :

:

{
countryList = retrieveProxy("YourProxyName").countryList;
useImmediatlyNewCountryList = false;
}

But there is plenty of other ways to achieve this. You can probably imagine something better in the context of your needs.

To test locally, you could use an HTTP proxy like ServiceCapture or Charles. After a little bit of configuration, they both be able to throttle your connection speed and you'll be able to test it locally as if you were on a server.

On a project I've worked for, a colleague of mine has successfully make the transition between download and initialization invisible. The best we can do is to hack the DownloadProgressBar to let it progress from the start to the middle and follow with the initialization from the middle to the end.

Ok, you want to display an InitIalizationProgressBar. To do this, you just have to use the same skin for your Flex DownloadProgressBar (there is plenty of tutorials on how to customize it on the internet or even adobe official documentation) and simply use the same skin for your own InitializationProgressBar. So, when the Flex preloading as been made, the Application.CreationComplete event dispatched you can display the InitializationProgressBar with a mediator that you will interest in all Initialization notification needed. Each time a notification is received, your InitializationProgressBar gain a level. Use custom property in your notification to tell the IntializationProgressBarMediator how much initialization steps are needed to complete the initialization.

I think that looking at StartupManager, StartupAsOrdered, StartupForAssets demos will help you a lot.

Be careful when you need to send a notification in the onRegister method. The onRegister method only guarantee that this mediator has been registered. If you have registered it through a prepViewCommand with other mediators, the next mediators in the list will not be registered at this time. If the mediators that aren't registered at this time are interested in the notification you send, they will not receive it.

You better have to send the notification when the view is added to stage. But you have to be sure that all PureMVC instances interested by this notification are already registered.