PureMVC Architects Lounge

I've been looking through the cafe townsend demo.  I have a question.  I'm developing an app with multiple 'pages'.  It looks like the author of the project used the file ApplicationMediator to switch between view stacks.  Is this the preferred way to switch between views? 

Generally, I like to expose a variable in the component that contains the ViewStack, and bind the stack's selectedIndex to it. Then whichever Mediator manages that component sets the property, causing the stack's selectedIndex to change without having to know that there's a ViewStack inside the component it's mediating.

Also, in that component, I like to expose public static constants that give names to the indices of the ViewStack, so that the Mediator also doesn't need to know the actual index numbers to use. The constants and the property to set or check become part of the API the component exposes to its Mediator.

-=Cliff>

Thanks for the info.  I'm a little confused, and this stuff is still pretty tough for me.  Do any of the demos work in the manner you are discussing, or do you have any other examples? 

Look at the architecture 101 demo. Examine the view components and their mediators. They're not switching viewstacks but populating forms and lists and grids. Same concept though. The view component exposes a public var for UserVO, which the mediator sets or gets. The grid or list or form fields bind to that public var and get updated when it changes.

-=Cliff>

Starting to make more sense now.  I'm still not there but I had a flash of thinking I knew what was going on, and that was cool.  I have another question that relates to this.  I've been reading about deferring view instantiation with PureMVC on a few forums.  I've been creating each 'page' of my app as a module and was going to load them when needed.  Am I going to have to do this deferred instaniation stuff?  Is this a good idea considering I'm developing an AIR app?

Thanks in advance.
Josh

When you say

"Generally, I like to expose a variable in the component that contains the ViewStack"

are you saying that I should have a component just for the viewStack, kinda like an empty movieclip in flash that I would load other movieclips into?  Do I even need to use a viewstack?  Should I be using modules for this?

Here's an example of a custom ViewStack component that exposes a simple API of a property and some constants for its valid settings.

Note that it binds its selectedIndex property to this 'currentViewSelector' property, which is initialized to the value for the LoginView child and can be manipulated by the Mediator for this component by setting it to one of the constant values.

MainDisplay.mxml -Take 1

<?xml version="1.0" encoding="utf-8"?>
<mx:ViewStack xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:view="com.me.myapp.view.components.*"
    selectedIndex="{currentView}">
   
    <mx:Script>
        <![CDATA[

            public static const GALLERY:String = 0;
            public static const EDITOR:String = 1;
            public static const PROFILE:String = 2;

            [Bindable] public var currentViewSelector:String = GALLERY;
           
        ]]>
    </mx:Script>

    <view:GalleryView/>
    <view:EditorView/>
    <view:ProfileView/>

</mx:ViewStack>


Why not just have the Mediator poke the value straight into the custom ViewStack component's selectedIndex property?

It'd expose too much of the internals of the component to assume that it is an ordinal that is being set and that it is in fact a ViewStack that is being managed.

Later you may wish to wrap this ViewStack and a group of buttons for controlling it into a single custom component extending, say VBox, rather than have the buttons remain separate and have their own Mediator.

So this Mediator now has a VBox for a child and that has no selectedIndex. But it retains a currentViewSelector property, so the Mediator isn't affected on that point.

MainDisplay.mxml - Take 2.

<?xml version="1.0" encoding="utf-8"?>
<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:view="com.me.myapp.view.components.*"
    >

    <mx:MetaData>
        [Event('showGallery')]
        [Event('showProfile')]
        [Event('showEditor')]
    </mx:MetaData>
   
    <mx:Script>
        <![CDATA[
            public static const GALLERY:String = 0;
            public static const EDITOR:String = 1;
            public static const PROFILE:String = 2;

            public static const SHOW_GALLERY:String = 'showGallery';
            public static const SHOW_EDITOR:String = 'showEditor';
            public static const SHOW_PROFILE:String = 'showProfile';

            [Bindable] public var currentViewSelector:String = GALLERY;
            public var activeView:Object;
        ]]>
    </mx:Script>
   
    <mx:Binding source="myStack.selectedChild" destination="activeView"/>

    <mx:ViewStack id="myStack" selectedIndex="{currentViewSelector}">
       <view:GalleryView/>
       <view:EditorView/>
       <view:ProfileView/>
    </mx:ViewStack>
   
    <mx:HBox>

       <mx:Button label="Gallery"
           enabled="{myStack.selectedIndex != GALLERY}"
           click="dispatchEvent(new Event(SHOW_GALLERY, true))"/>
       
     <mx:Button label="Editor"
           enabled="{myStack.selectedIndex != EDITOR}"
           click="dispatchEvent(new Event(SHOW_EDITOR, true))"/>

       <mx:Button label="Profile"
           enabled="{myStack.selectedIndex != PROFILE}"
           click="dispatchEvent(new Event(SHOW_PROFILE, true))"/>

   </mx:HBox>

</mx:VBox>


The Mediator still sets the currentView property to affect the displayed view, even though the component implementation is completely different. The ViewStack still binds to this value for its selectedIndex.

So lets think about what this Mediator might look like and do. It'd be silly to have it be there for no other purpose than to listen to the buttons and switch the view. If that were the case, then we'd encapsulate it all inside the custom component, having the buttons directly  change the ViewStack child.

However, perhaps we need the rest of our application to know that we have switched the displayed child. Perhaps each one has a different background color associated and the ApplicationMediator listens for the change and changes its background color. Or whatever.

So we know at a minimum we'll listen for the button click events and set the appropriate value for currentViewSelector, and we'll send a Notification to the rest of the system.

But while we're at it, lets not skirt the big issue here:

Unless that ViewStack has creationPolicy='all' (not recommended) and you've elsewhere added all the Mediators for the children, you've got a problem. Deferred instantiation behavior of a ViewStack means that the first child is created, but the others don't exist until we navigate to them.

The MainDisplayMediator gets the sole reference MainDisplay as its View Component so lets put it in charge of the problem of making sure the children of its View Component get the appropriate Mediators created and registered for them as soon as they are created.

We know that the first one will be created right away. So in our constructor, we can create the mediator for it.

Then, whenever we get button presses that toggle the current view, we set the currentViewSelector, check for and create a mediator for the new child if necessary, and then send a notification to the rest of the system that that view has been selected. It is important to check for and create the mediator first before sending the Notification, because other actors in the system will probably want to interact with it as a result of the Notification.

Note that in the MainDisplay.as Take 2, we added another variable 'activeView' and bind the currentChild of the viewStack to it. That will be used to reach the new child we'll be creating a Mediator for.

MainDisplayMediator.as - (NOTE: This is a PureMVC 2.0 style Mediator, the slight differences are org.puremvc.as3 package, sending NAME to the constructor and not having to override getMediatorName)

package com.me.myapp.view
{
        import com.me.myapp.view.components.MainDisplay;
import org.puremvc.as3.interfaces.INotification;
import org.puremvc.as3.patterns.mediator.Mediator;

public class MainDisplayMediator extends Mediator
{
public static const NAME:String = 'MainDisplayMediator';

public function MainDisplayMediator( viewComponent:MainDisplay )
{
super( NAME, viewComponent );

                        mainDisplay.addEventListener( MainDisplay.SHOW_GALLERY, onShowGallery );
                        mainDisplay.addEventListener( MainDisplay.SHOW_EDITOR, onShowEditor  );
                        mainDisplay.addEventListener( MainDisplay.SHOW_PROFILE, onShowProfile );
                        checkForMediator(  MainDisplay.currentViewSelector, mainDisplay.activeView );
}

protected function get MainDisplay():MainDisplay
{
return viewComponent as MainDisplay;
}

protected function onShowEditor(event:Event):void
{
mainDisplay.currentViewSelector = MainDisplay.EDITOR;
                        checkForMediator(  MainDisplay.EDITOR, mainDisplay.activeView );
                        sendNotification( ApplicationFacade.EDITOR_MODE );
}

protected function showGallery(event:Event ):void
{
mainDisplay.currentViewSelector= MainDisplay.GALLERY;
                        checkForMediator(  MainDisplay.GALLERY, mainDisplay.activeView );
                        sendNotification( ApplicationFacade.GALLERY_MODE );
}
 
protected function showProfile(event:Event ):void
{
mainDisplay.currentViewSelector = MainDisplay.PROFILE;
                        checkForMediator(  MainDisplay.PROFILE, mainDisplay.activeView );
                        sendNotification( ApplicationFacade.PROFILE_MODE );
}

                protected function checkForMediator( childSelector:String, child:Object ):void
                {
                        switch (childSelector)
                        {
                             case MainDisplay.PROFILE:
                                  if ( retrieveMediator( ProfileViewMediator.NAME ) == null )
                                     facade.registerMediator(new ProfileViewMediator( child ));
                                  break;
                             case MainDisplay.GALLERY:
                                  if ( retrieveMediator( GalleryViewMediator.NAME ) == null )
                                     facade.registerMediator(new GalleryViewMediator( child ));
                                  break;
                             case MainDisplay.EDITOR:
                                  if ( retrieveMediator( EditorViewMediator.NAME ) == null )
                                     facade.registerMediator(new EditorViewMediator( child ));
                                  break;
                        }
         
                }

}
}


Wow!  Thanks for all the info.  I'm trying to digest it, and get this stuff straight.  Probably be back with a few questions.

Thanks again,
Josh

Not to switch gears here, but do I even need a viewstack, or should I just adjust my components visible values in the mediators.  If I just register my components to listen for the correct events I should be able to handle everything in the mediator right?  Is that a bad way to do it.  Sorry for all these questions, but this is really new to me.   

You could do that but then you'd be burdening your Mediator with the logic that the ViewStack already handles. If you're in Flash, or a platform with no ViewStack type inmplementation, then I suppose you'll have to resort to something.

But there's no sense rebuilding that wheel if you're using Flex or AIR. It gives you deferred instantiation, which is a good thing. The startup time of your app is critical, and object creation overhead has its impact. If you can defer the creation of the children not shown, then your app comes up quicker.

You could of course handle deferred instantiation in the Mediator as well, but again that would be over-complicating the Mediator. The more appropriate place would be a Command, but that's pushing it deeper into the framework and causing a new class to deal with it.

-=Cliff>

Yeah, about commands.  I've read your documentation, read a ton of blogs about puremvc and thought I understood them until I started working with this stuff.  I don't see any reason to do any commands yet in my application (outside of startup).  Do commands make more sense when you have more than one thing to do off of an event?  Right now my stuff is real basic, pressing a button and then switching a viewstack selected index.

Also, earlier in this post you wrote
selectedIndex="{currentView}"

did you mean selectedIndex="{currentViewSelector}"

or am I super dense?

Your correction is correct.

And while Commands are something that are a bit broadly used in other frameworks, they definitely have a place here in PureMVC-land.

Commands are great when the same functionality needs to be accessed from multiple places in the view. For instance, a PasteCommand might retrieve the ClipboardProxy and get the current clipboard object, and then retrieve the current view context (are we in a text editor, a canvas, etc) and make sure the clipboard object type is accepted by the current view context. If so, send a notification with that object as the body. The appropriate mediator responds and sets the data on its child.

That PasteCommand could be triggered from a keystroke or a menu click, heard by different mediators. They would each send the PASTE Notification, rather than do than duplicate that work in two mediators.

-=Cliff>

Thanks again.

Oh man, I think I just understood your mainDisplay take 1 take 2 Post!!  That is exciting for me:>   

Hi!

was happy to find this topic, as my application is nearly only viewStack based components inside eachothers... but it doen't work.
I'm not new with MVC+C (AS2 pixlib addict :) but Flex and PureMVC are new for me.

can somebody tell me where I'm wrong?

main.mxml has :
     2 perso very simple components (for navigation, so contains only buttons)
     one viewStack, holding either a Home.mxml component or a antoher view
     and cliff'code with activeView and currentView, etc...


I've put all the habitual staff with Startup Notification : this works

the startup command is a macrocommand, calling ModelPrep and then ViewPrepCommand... this works also

the viewPrep Command registers my ApplicationMediator :
     the constructor has this
super(NAME,viewComponent);
trace("app : "+app);  // traces the get method for giving back casted viewcomponent
trace("app nav : "+app.toolBar);   // traces the first simple navigation component
trace("currentView : "+app.currentViewSelector);
trace("activeView : "+app.activeView);
checkForMediator(app.currentViewSelector,app.activeView);
the result is:
app : Main
app toolbar : Main.toolBar
currentView : 0
activeView : null


I always get a null has main viewstack item but it's displayed on the screen...
so when is it created, why do I receive a null ??

please help
thx

Makar

Can't really tell, since I don't know what checkForMediator does.

-=Cliff>

the checkForMediator is the same as yours : try to retrieve proxy, and create it if null.
but the problem doesn't come from the method, but from the "activeView" returning null at first time.
it's not binded at the beginning, so we can't instanciate it as you do in your exemple.

it only works if I add a "activeView=viewstack.selectedChild" on the onCreationComplete event.
and if my viewstack.selectedChild contains himself another viewStack, then I have to add a creationComplete event also in my mediator since I can't access directly the children in the constructor.

(there's also the public const GALLERY, etc... that you cast as strings... they might be an int, isn't it?)

thanks,
PiR

Yes, those strings should be int.

As for your viewstack in a viewstack, I'd simplify the problem by giving each viewstack its own mediator. Then the deferred instantiation problem is easier to deal with.

And why do you not bind activeView?

-=Cliff>

I do bind activeView, but it's not binded at the application startup, (or after the mediator instanciation).

and I actually have a mediator for each viewstack item, but I need to have several viewstacks. it's easier to explain with this:

Main.mxml contains:
    - NavComponent.mxml (linked to mediator)
    - InfoBarComponent.mxml (linked to mediator)
    - a viewStack with (at this time) 2 view items HomeComponent.mxml and MessageBoard.mxml (both linked to related mediators)

HomeComponent.mxml contains:
    - several buttons sending notifications linked to a command, and listened by MainMediator to make the viewStack switch between different views (at this time only messageBoard available)

MessageBoard.mxml contains:
    - a viewStack with 3 items ListMessagesComponent, ReadMessageComponent and WriteMessageComponent (all linked to mediators)


you can then see that when I launch my app, it calls the HomeComponent in the main viewstack. We then select the "message board" button, wich calls the MessageBoard component in the main view stack.
with this, there is no problem with your method.
but if I use your method in chain (so if I call my ListMessageMediator in the MessageBoard constructor), I receive a "null" because flex seems to need a time to show the main viewstack item, and another time to show the message viewstack.


I got my solution adding a onComplete event listener in my ListMessageMediator (and so in other mediators)

do you think on an easier way?

makar

Makar,

You're right in handling it with an event sent onCreationComplete for the component in question.

Make that event bubble, and it could be handled by any Mediator attached to any display component up the hierarchy, take your pick.

Usually I have the immediate parent handle it but if there is a lot of depth with this happening at each level, it can be a good idea to have a top-level ApplicationMediator catch the event, and send it to a Command that can do a lookup on the component id or other property and instantiate and register the correct Mediator from an internal hash or switch/case.

-=Cliff>

Cliff thanks for the great sample code!

I have it about 95% implemented.  What I'm finding is the dynamically instantiated Mediators are not receiving Notifications from my proxy.  Just as I had pulled out my last fistful of hair I registered my MainViewMediator to listen for the notifications and it worked as expected.

Short of posting my code can you guys think of anything I may have missed?

phragm3nt

You might've forgotten to add the notifications to the array returned from their listNotificationInterests() methods.

If that's not it, I suggest setting a breakpoint on the.line of the Proxy where the missed note is being sent.

Run in debug mode and when it stops at the breakpoint, use the debugger variables view to inspect the facade property. From there you can see everything.

Note you'll need to select 'Show inaccessable member variables' in the Flex menu. That's on the downward pointing triangle widget to the right of the variables view tab in Flex Builder/Eclipse.

Open facade then view, then mediatorMap to see if they're actually there. If so, open observerMap to be sure that, for the notifications in question, there are Observer instances registered pointing to the Mediators in question.

If the above isn't true then you've dropped the ball on getting the Mediators registered before the Proxy sends this notification that's being missed, so move your breakpoint closer to the problem; where the mediator is created and registered.

The debugger is your best friend. Visit it occasionally, it misses you :)

-=Cliff>

Hey Cliff,

I will give that a shot this evening!  Thanks so much for the ideas!  I do have the interests listed in the array and in the handler with breakpoints!

So I'll dig in with the debugger to see what's going on!

Thanks again,

phragm3nt

It turns out I neglected to add a call to "checkForMediator" in my Event Handler in the MainViewMediator.

Everything is working great!

Thanks,

phragm3nt

Quick note to say thank you very much Cliff.  I have been working through a lot of the examples on here and have learnt about all I need, to be productive, and hopefully profitable, with Flex and PureMVC.

All thanks to posts like these. 

Thanks once again.

Yes, the Take 1/Take 2 post was extremely helpful in explaining a few things for me.

Questions:

1. In the checkForMediator function I get a 'possibly undefined method' error on the retrieveMediator call.  The class I'm using it in is MyMediator extends mediator implements IMediator - just like in the example.  I noticed in a search of the forums for 'retrieveMediator' that someone had facade.retrieveMediator, and in the Framework Overview it shows a retrieveMediator method on Facade and View classes, but not the Mediator class.  Is there something different I should do to check for the existence of mediators for views that use deferred instantiation?

2. (this one's minor) I noticed you are using buttons to switch views in the ViewStack in the example and have the mediator code setting the public property currentViewSelector to which the ViewStack's selectedIndex is bound.  I decided to use a TabBar to switch the views in the ViewStack and have the parent component mediator's event handling code simply check for the view mediator and send a notification to the facade for further use.  I have the ViewStack set as the dataProvider for the TabBar and the mediator listens for the ViewStack's change event.  Does this sound right and is the order of events right, or am I violating any idioms or best practices?

Thanks much.

1) Use facade. The  code example was in error.

2) Sounds good to me.

-=Cliff>

Hi.

I am trying to work my way through this, using Cliff's example code, but I am getting the following error:

1118: Implicit coercion of a value with static type Object to a possibly unrelated type org.puremvc.as3.demos.flex.employeeadmin.view.components:EditorView

The error is pointing to the checkForMediator function:

protected function checkForMediator( childSelector:int, child:Object ):void
                {
                        switch (childSelector)
                        {
                             case MainDisplay.PROFILE:
                                  if ( facade.retrieveMediator( ProfileViewMediator.NAME ) == null )
                                     facade.registerMediator(new ProfileViewMediator( child ));
                                  break;
                             case MainDisplay.GALLERY:
                                  if ( facade.retrieveMediator( GalleryViewMediator.NAME ) == null )
                                     facade.registerMediator(new GalleryViewMediator( child ));
                                  break;
                             case MainDisplay.EDITOR:
                                  if ( facade.retrieveMediator( EditorViewMediator.NAME ) == null )
                                     facade.registerMediator(new EditorViewMediator( child ));
                                  break;
                        }
         
                }

I can see that it's to do with the 'child' argument that is passed in, which is taken from mainDisplay.activeView.

Anybody got any ideas?

Thanks,

Neil

I've figured out my problem above, but now have something else.

I have a viewstack that triggers the relevant mediator for a view.
However, that view contains other componenets that have their own mediator. Where and how do I call the mediator for this component within a view?

I have tried adding it to the MainDisplyMediator so that when the parent view is called and it's mediator registered, it try's top register the mediator for the component, but how do I pass in the viewComponent?

I have:

case MainDisplay.CLIENTS:
 if ( facade.retrieveMediator( ClientViewMediator.NAME ) == null )
 facade.registerMediator(new ClientViewMediator( child ));
 facade.registerMediator(new ClientListMediator( child ));

The child argument refers to ClientView, which is the parent view, but I assume child would need to be ClientList for the second registration.

I hope that makes sense and that someone can help!!

Thanks,

Neil

If you register ClientListMediator from within ClientViewMediator, you'll have a reference to the list as an immediate child of the viewComponent ClientView.

-=Cliff>

Hi Cliff.

Thanks for that, it got it working.

Now I have something else...

I have a pop up that is created when a record is clicked on the ClientList, using the pop up manager elsewhere on this forum. The pop up view is called ClientForm.
Where do I register the mediator for ClientForm?

Do I need to add a creationComplete notifier on the ClientForm, so that when the ClientForm is created it triggers the registeration of the ClientFormMediator. If so, how do I pass the viewComponent?
From an event listener, I can't pass an arugument (viewComponenet) to the target function.

Is the pop up considered a child of ClientView or ClientList, or is it a seprate entity?

Thanks,

Neil

Forget that, the mediator is already registered by the pop up manager.  ::)

Here's a link to the newly created FAQ entry for this problem:

http://puremvc.org/content/view/91/185/

-=Cliff>