Futurescale, Inc.
PureMVC Home
The PureMVC Framework
Code at the Speed of Thought
Over 10 years of community discussion and knowledge are maintained here as a read-only archive.
New discussions should be taken up in issues on the appropriate projects at
https://github.com/PureMVC
PureMVC Architects Lounge
Announcements and General Discussion
Getting Started
Two questions about Slacker
Pages: [
1
]
« previous
next »
Author
Topic: Two questions about Slacker (Read 8360 times)
willw
Full Member
Posts: 30
Two questions about Slacker
«
on:
January 07, 2009, 09:25:21 »
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
Logged
Roustalski
Jr. Member
Posts: 13
Re: Two questions about Slacker
«
Reply #1 on:
January 08, 2009, 05:18:03 »
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*
Logged
willw
Full Member
Posts: 30
Re: Two questions about Slacker
«
Reply #2 on:
January 09, 2009, 04:11:30 »
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
Logged
puremvc
Global Moderator
Hero Member
Posts: 2871
Re: Two questions about Slacker
«
Reply #3 on:
January 09, 2009, 04:59:47 »
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>
Logged
Pages: [
1
]
« previous
next »
Stack Overflow
GitHub
Linked In
Google Plus
Twitter
Powered by SMF 2.0.15
|
SMF © 2006-2007, Simple Machines LLC
|
Content © 2006-2018, Futurescale, Inc.
Loading...