PureMVC Mediators and views - creation and control

Question

I'm making an app with flash AS3 and puremvc, the way to correctly handle view mediators is sort of throwing me a little...

OK - I have 3 or 4 distinct views, each governed by it's own mediator. Each view is only displayed on its own - ie. when 1 is visible/on stage - the others are invisible/removed from stage (over simplified, but I guess could be thought of as seperate pages, viewed one at a time, a nav bar allows a user to change views when they like)

At first each view mediator I had creating and added to stage it's own view component, and as such, when it was 'turn' to show or hide that view, it was simple - addChild and removeChild for it's view component.

However, I read over at puremvc.org that it's not good practice to a. pass round the stage (which was the viewComponent for each mediator in my case - where each view was added to - eg. viewComponent.addChild(foo) b. create its own view - which allowed me to add and remove it in the first place.

So I changed to the recommended way - when I create each mediator, what I pass in is the view component it governs (rather than the stage/main doc class)

eg.

var view:MyView = new MyView();
facade.registerMediator( new MyViewMediator( view ) );
viewComponent.addChild(view);

So - with that the case - I have no idea how I would go about removing/adding each view when needed. I could easily enough set the visibility from within each mediator, but I sort of wanted to avoid doing that - prefer removing when not in use for resource management...

Anyone got any good ideas either how I am 'meant' to go about this (as in, when a view is no longer needed on stage, remove it - temporarily, and add it later on when it is needed?) - or am I missing some point (quite likely!) and going about this the wrong way? I'm very new to puremvc so not too confident I am approaching it right. Pointers most welcome!

Answer 1

I won't pretend to be an expert in PureMVC, but the way I like to work is to only create a Mediator for major areas of the site. For example, a HeaderMediator, FooterMediator and ViewMediator. Then, I have an ApplicationMediator that "onRegister" will create the other mediators just mentioned. This way, I'm not creating a mediator for each individual view and the "ViewMediator" handles switching between views. Here is what my "onRegister" function would look like:

override public function onRegister():void {
    var viewContainer:Sprite = viewComponent.addChild(new Sprite()) as Sprite;
    facade.registerMediator(new ViewMediator(viewContainer));

    var headerContainer:Sprite = viewComponent.addChild(new Sprite()) as Sprite;
    facade.registerMediator(new HeaderMediator(headerContainer));

    var footerContainer:Sprite = viewComponent.addChild(new Sprite()) as Sprite;
    facade.registerMediator(new FooterMediator(footerContainer));
}

Next, I'll have a ViewProxy that has a pool of views sitting and waiting to be called up (in an Array, Dictionary or Vector). When it's time to change or set a view, I use a ChangeViewCommand that retrieves the view from the ViewProxy and sends a notification (like SET_VIEW) with the view object as the body.

Now, the ViewMediator will handle the notification "SET_VIEW". If it's something as simple as removeChild(oldView) and addChild(newView) then I will just handle it in the Mediator itself. If a transition is necessary and involves more code, then I'll use a command to handle the transition.

Hope that makes sense and helps. Of course, I like to change things up and try new things, so if you have any concerns or suggestions I'm open to hearing them.

Answer 2

May I ask your motivation for using PureMVC ? I don't want to start a holy war here, but one of the reasons behind the creation of the second generation frameworks (Mate,Swiz,Robotlegs,Parsely) was because of the absurd amount of difficulty in getting started with RIA application architecture.

Don't feel bad though, the newer frameworks have documentation, so it is easy to understand and figure out the motivation for all of the components, paradigms and actors that come into play.

Answer 3

As FlexFiend mentioned, this situation is easier to take care of in second generation frameworks (at least it is in Robotlegs, I can't speak for the others). This is because, usually, you never explicitly create or destroy a mediator in Robotlegs; instead, you associate a mediator with a view component and Robotlegs constantly watches the stage for view components being added and removed and creates and destroys instances of the appropriate mediators.

Therefore one approach for implementing this kind of thing in PureMVC is to have a StageMediator with the stage itself as its view component, and listen for Event.ADDED_TO_STAGE and Event.REMOVED_FROM_STAGE events. Finally you will need a system to associate view components with mediators. Check out https://github.com/robotlegs/robotlegs-framework/blob/master/src/org/robotlegs/base/MediatorMap.as to see how its done in Robotlegs.

I am actually about to implement something like this since I am working on a project which is part of a suite of PureMVC applications, but honestly unless you have no choice I would say the easiest thing to do is simply to use Robotlegs!