Two questions about Slacker

[willw]

First: PureMVC (as everyone else correctly says) is indeed an excellent and wonderful thing, and I am most grateful for it. But I am very new to it, so please excuse a couple of silly questions.

I have quickly arrived at the deferred instantiation problem in my app, and have found the Slacker example. It seems to work fine, but I don't understand the reasoning behind the following code extracted from MainDisplayMediator.as.

The onXXXCreated() functions below are called from the creationComplete events of the respective components. It is the handling and checkForMediator() implementation that puzzles me:

    public class MainDisplayMediator extends Mediator
    {
    //...
        protected function onEditorCreated( event:Event ):void
        {
            checkForMediator( MainDisplay.EDITOR, mainDisplay.activeView );
        }

        protected function onGalleryCreated( event:Event ):void
        {
            checkForMediator( MainDisplay.GALLERY, mainDisplay.activeView );
        }
 
        protected function onProfileCreated( event:Event ):void
        {
            checkForMediator( MainDisplay.PROFILE, mainDisplay.activeView );
        }


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


My two questions are:
1) Is this a case of the switch statement being deliberately used to emphasise simplicity? I don't like the way that integer manifest constants like MainDisplay.PROFILE must be translated into a class ProfileViewMediator, which seems fiddly and hard to maintain. I want to write

        protected function onProfileCreated( event:Event ):void
        {
         checkForMediator( ProfileViewMediator, mainDisplay.activeView );
        }

//... etc for each tab

        protected function checkForMediator( mediatorClass:Class, child:Object ):void
        {
          if ( ! facade.hasMediator( mediatorClass.NAME ) )
            facade.registerMediator(new mediatorClass( child ));           
        }
and simplify the code. Is this 'bad style' in PureMVC terms?

2) Why do we need the check to see if the mediators have already been created anyway? We are in the CreateComplete event for the component, which surely only gets called once for the lifetime of the component. The code is specific to the handler. So one could safely write

        protected function onEditorCreated( event:Event ):void
        {
           facade.registerMediator(new EditorViewMediator( mainDisplay.activeView ));
        }

Am I missing something?

Best regards

Will

[Roustalski]

I haven't seen the demo you are talking about, but:

1. You are right in my opinion, where it would be cleaner to just pass in a the class rather than an integer that corresponds to a class.

2. The only thing I can think of is that the component would load multiple times at runtime and therefore potentially fire the events multiple times. That is also of course assuming that cleaning up of the mediators via removeMediator() from the facade was not called. (even though I thought I remember a thread explaining why we might not want to remove mediators due to efficiencies sake. *shrug*

[willw]

Thanks for that.

In the demo app, the components were created just the once and never destroyed. I suppose the code could be intended to demonstrate a more general case.

To argue against myself in the case of passing the class: I depend on the presence of the NAME static constant, and that the constructors of the classes all have the same signature. In practice I think they all do, but (scarily to a busking C++ programmer who is slightly alarmed by all this absence of static type checks) there is no way to check this until the code runs.

Will

[puremvc]

Because the viewStack is a more common problem, I used it rather than view states. The mediator code could indeed skip the checking for a mediator. However if using Flex view states, the unique components for a state are removed and may later be created again. In that case you do need this check. And further (for states), you should have the mediators listen to their view components for removed events, at which point they null their view component reference and remove themselves with facade.removeMediator.

And the reason you can't use a class to check registration is that mediators are registered by name. Most of the time one instance of a mediator is all that is registered. Convention is to use a NAME constant for the name. But if a mediator will have more than one instance registered, then NAME clearly doesn't work. A unique name must be passed to super in the mediator constructor.

See the HelloFlash demo for a mediator that has multiple simultaneously registered instances with unique names.

Also, the compiler will definitely tell you if a constant reference isn't resolved; malform one of the constants, it won't make it to runtime.

-=Cliff>