tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/25-mediator-onregister-happening-after-startup_completeRobotlegs: Discussion 2018-10-18T16:35:07Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-06T16:05:02Z2010-01-06T16:05:02ZMediator onRegister happening after STARTUP_COMPLETE<div><p>Hi Joe,</p>
<p>Mediators work a little differently in Robotlegs - when we write
this:</p>
<pre>
<code>mediatorMap.mapView( ViewClass, MediatorClass )</code>
</pre>
<p>we are instructing Robotlegs to automatically create and
register mediators when instances of ViewClass land on the stage.
This means that a mediator won't exist until its corresponding view
component has been added to the display list.</p>
<p>You are experiencing difficulty because you are trying to access
a mediator directly from a command, which is not good practice -
your application should be "unaware" of its view tier. When you
directly manipulate mediators from commands/models/proxies etc, you
couple your application to its view tier - which is exactly what
MVC is designed to avoid.</p>
<p>Rather than talking directly to a mediator from your command you
should dispatch an event - one that the mediator itself will
respond to. Before you dispatch the event make sure that you have
added the necessary view component to the display list (so that its
mediator will be created, registered and ready to respond to the
event).</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-06T16:24:14Z2010-01-06T16:24:16ZMediator onRegister happening after STARTUP_COMPLETE<div><p>Thanks - the problem I have is not knowing when the view is
completely ready so I may access it. I think I'll probably need to
create some kind of ApplicationStateModel to keep tabs on what's
been set up, and also to dispatch events when things have been set
up.</p>
<p>One point I'm not too clear on though... You say that accessing
a mediator directly from a command isn't good practice... But how
about accessing the model from the command? Doesn't that make the
layers just as coupled?</p></div>Joetag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-06T16:37:15Z2010-01-06T16:37:17ZMediator onRegister happening after STARTUP_COMPLETE<div><p>One other thing (sorry) :)</p>
<p>I guess I've been calling the view layer directly from the
command layer because I think of Events as "I've done something"
information, rather than "Do this" information, if that makes
sense... So I guess I need to get used to Events telling mediators
to do stuff...?</p></div>Joetag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-06T23:10:51Z2010-01-06T23:10:51ZMediator onRegister happening after STARTUP_COMPLETE<div><p>"I've done something" is actually the better way to think of
events; I'm not suggesting that you create events that "tell"
mediators to do things, I'm suggesting that mediators should act in
response to events - the difference is pretty subtle I know.</p>
<p>If you map a mediator to a view class, and then add an instance
of that class to the display list, you can assume that a mediator
will be constructed and ready for action immediately.</p>
<p>Getting back to your original problem, I wouldn't try to access
the mediator from the command directly, instead I would dispatch an
event at the end of the command that the mediator would respond to.
The event would describe what happened in that command, rather than
a call-to-action event designed specifically for the mediator.</p>
<p>Perhaps a way to think about it is:</p>
<p>A view is just that - <em>a</em> view. One single view onto a
part your application. You should be able to add another view (or
even another instance of that same view) and your application
should still work. Like changing the camera in a first-person
shooter, or that little rear-view mirror in a racing game; just
different views of the same application.</p>
<p>Does that help?</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T14:04:10Z2010-01-08T14:04:10ZMediator onRegister happening after STARTUP_COMPLETE<div><p>Yes I think so, thanks! I guess I'd become quite lazy in my
PureMVC programming ways, and so it's good to get a bit of a
refresher on how to separate things properly in an MVC
framework.</p>
<p>One thing I am struggling with, however, is finding a point at
which my view is completely set up and ready to go. I have only one
Application View, and that has four custom view components in it,
each with an associated mediator. However I am finding that even if
I try to access the mediators from a "contentCreationComplete"
action, they are not yet registered.</p>
<p>But then I think again about what you said regarding the
decoupling of the view... I guess what I really need to do is have
the Mediators request information when they know they have been
registered... Sorry I'm thinking this through as I discuss it here
:-) I will go back through my set-up and see how I can alter things
accordingly.</p>
<p>Cheers,</p>
<p>:-Joe</p></div>Joetag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T14:14:29Z2010-01-08T14:14:29ZMediator onRegister happening after STARTUP_COMPLETE<div><p>Ah, with Flex a mediator's onRegister hook will only be called
after creationComplete. So, the mediator gets created as soon as
the view component lands on stage, but onRegister only gets called
when the view component dispatches creationComplete. With plain
as3, onRegister gets called sooner (immediately after the component
is added to stage).</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T14:22:09Z2010-01-08T14:22:09ZMediator onRegister happening after STARTUP_COMPLETE<div><p>That's good to know thanks. I'm probably going to be moving the
project to plain AS3 so as to save on overheads, but I think it'd
probably be good practice to see if I can change the code so that
it will work without being PUSHED data when ready... I'm thinking
I'll probably get each Mediator to dispatch a [mediatorName]_READY
event when they are ready... The problem is that if the event has
already been dispatched before another mediator has been created,
then I guess the only ways for amediator to test to see if another
mediator exists are:</p>
<ol>
<li>Inject that mediator into the other mediator (probably not good
practice?)<br></li>
<li>Create a MediatorManagerModel class which stores information
about which mediators are ready and which ones aren't</li>
</ol>
<p>Any thoughts or suggestions?</p></div>Joetag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T14:30:40Z2010-01-08T14:30:40ZMediator onRegister happening after STARTUP_COMPLETE<div><p>Hmmm.. that all sounds way too complex and fragile to me.
Perhaps you could attach a simplified version of your codebase, or
write up a more detailed description of what you are wanting to
achieve. I'm sure there is a much simpler solution to your
problem.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T14:47:05Z2010-01-08T14:47:05ZMediator onRegister happening after STARTUP_COMPLETE<div><p>Perhaps the slight delay (caused by waiting for
creationComplete) is giving you trouble due to your data not being
loaded asynchronously - ie, the data is ready 1 frame before the
view is ready. Just a thought..</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T15:22:17Z2010-01-08T15:22:17ZMediator onRegister happening after STARTUP_COMPLETE<div><p>Yes, that is pretty much what the problem is. Offline, the data
loads immediately and so the mdel is ready before the view. But
online, the view might well be ready before the model.</p>
<p>I think I need to alter the view so that it just checks the
model once it is ready... I will look at the problem with a fresh
pair of eyes tonight, and possibly post some of the code for
scrutiny!</p>
<p>Just for the record, the app is a generic showreel creator,
driven by XML (images, transitions, durations, randomize etc). The
model stores the XML and keeps tabs on which slide is the current
one etc... The view layers include the SlideMediator (the main
slide showing layer), the NavigatorMediator (for showing the
thumbnails and being able to jump between slides), the
TransportMediator (for play/pause) and the LoadingMediator (for
showing a loading bar if the image has not yet loaded).</p></div>Joetag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T15:31:36Z2010-01-08T15:31:36ZMediator onRegister happening after STARTUP_COMPLETE<div><p>In that case, here's a possible way to approach it:</p>
<p>You inject the model into the mediator. In the mediator's
onRegister hook you check to see if the model is ready. If it's not
you add a listener for a ModelReady kind of event (remember that
models should dispatch events when their state changes
significantly), if it <em>is</em> ready, then proceed as
normal.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T15:46:25Z2010-01-08T15:46:25ZMediator onRegister happening after STARTUP_COMPLETE<div><p>Thanks... I think the problem is that I was using a Command for
dealing with when the model is ready...</p>
<p>At startup, the model is initialized, the config XML loaded, and
once loaded into the model I dispatch a CONFIG_LOADED event. From
there I had a ConfigLoadedCommand which then set the model to the
first slide of the first album, and then told the view to start
playing.</p>
<p>I don't really want to put that into the model, because that's
business logic, so I'm not sure exactly how to tell the view to
start showing the images...</p></div>Joetag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T16:00:24Z2010-01-08T16:00:24ZMediator onRegister happening after STARTUP_COMPLETE<div><p>[I tried to email this, but don't think it arrived. Hopefully it
doesn't post twice!]</p>
<p>Configure Services -> Configure Model -> Initialize View
-> Viewing</p>
<p>It's a State Machine</p>
<p><a href=
"http://github.com/joelhooks/robotlegs-examples-UnionPlatformChatClient/blob/master/src/org/robotlegs/examples/bootstrap/controller/configuration/BootstrapApplicationCommand.as">
http://github.com/joelhooks/robotlegs-examples-UnionPlatformChatCli...</a></p>
<p>It doesn't add much complexity and gives you as fine of grain of
control as you could hope to have on your bootstrap process.</p>
<p><a href=
"http://github.com/joelhooks/robotlegs-utilities-StateMachine">http://github.com/joelhooks/robotlegs-utilities-StateMachine</a></p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T17:59:14Z2010-01-08T17:59:14ZMediator onRegister happening after STARTUP_COMPLETE<div><p>To me this sounds like a really good use case for the Loadup or
StateMachine utilities. Control the bootstrapping. Like a boss.</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-08T18:01:41Z2010-01-08T18:01:41ZMediator onRegister happening after STARTUP_COMPLETE<div><p>Configure Services -> Configure Model -> Initialize View
-> Viewing</p>
<p>It's a State Machine</p>
<p><a href=
"http://github.com/joelhooks/robotlegs-examples-UnionPlatformChatClient/blob/master/src/org/robotlegs/examples/bootstrap/controller/configuration/BootstrapApplicationCommand.as">
http://github.com/joelhooks/robotlegs-examples-UnionPlatformChatCli...</a></p>
<p>It doesn't add much complexity and gives you as fine of grain of
control as you could hope to have on your bootstrap process.</p>
<p><a href=
"http://github.com/joelhooks/robotlegs-utilities-StateMachine">http://github.com/joelhooks/robotlegs-utilities-StateMachine</a></p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/8101962010-01-09T20:45:34Z2010-01-09T20:45:34ZMediator onRegister happening after STARTUP_COMPLETE<div><p>That looks great, thanks! Is there any documentation on how it
works?</p></div>Joe