tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/193-mediator-onregister-called-more-than-once-with-views-excludefromRobotlegs: Discussion 2018-10-18T16:35:19Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/34453412010-10-21T13:33:38Z2010-10-21T13:33:38ZMediator onRegister called more than once, with view's "excludeFrom".<div><p>I'm an AS3 rather than flex user, but the excludeFrom / includeIn Flex stuff refires the addedToStage event that triggers the Mediator to run onRegister();</p>
<p>So... you might need to manually mediate, and not autoCreate/autoRemove by overriding the defaults in your mediatorMap.mapView:</p>
<pre><code>public function mapView(viewClassOrName:*, mediatorClass:Class, injectViewAs:* = null, autoCreate:Boolean = true, autoRemove:Boolean = true)</code></pre>
<p>However, in many cases it doesn't matter that the onRegister runs again, because you want your mediator to live and die with your view (when you excludeFrom it should be removed/cleaned up). It rather depends what's happening in onRegister. Usually all that is happening is that you're listening for events on the view (or signals) and on the central eventDispatcher.</p>
<p>Hopefully that helps you figure out which (automatic or manual) is going to suit you.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/34453412010-10-21T14:14:09Z2010-10-21T14:14:09ZMediator onRegister called more than once, with view's "excludeFrom".<div><p>Sweeet!<br />
I had to find where to put those mediatorMap.createMediator calls (I chose to put those calls in my main Mediator's onRegister) and how to sort them but that's it, easy.</p>
<p>On a side-note: don't give the id "statusBar" to any of your components in your Flex project, you will end up searching for a bug that doesn't even exist...</p>
<p>Thanks!</p></div>Quentintag:robotlegs.tenderapp.com,2009-10-18:Comment/34453412010-11-16T15:56:07Z2010-11-16T15:56:07ZMediator onRegister called more than once, with view's "excludeFrom".<div><p>Wouldn't you recommend overriding <code>onRemove</code> instead of manually mediating those views?<br />
It looks much cleaner to simply <code>.mapView(ViewClass, ViewClassMediator);</code> and add event listeners in the mediator's <code>onRegister</code> and then remove them in its <code>onRemove</code>, or at least to me.</p>
<p>Thoughts?</p></div>Quentintag:robotlegs.tenderapp.com,2009-10-18:Comment/34453412010-11-29T15:17:44Z2010-11-29T15:17:44ZMediator onRegister called more than once, with view's "excludeFrom".<div><p>Hi Quentin -</p>
<p>as I said, it all depends on what happens in your onRegister /
onRemove.</p>
<p>The possible difficulty I can see is that if you use the
automatic mapping then the mediator is being created / destroyed
each time. Therefore it has no state - so you can't necessarily
rely on that to decide whether to rerun your onRegister code.</p>
<p>You also end up with logic in your mediator ... which some of us
think is a very bad thing, and other people don't worry about - it
all depends whether you're trying to follow the mediator pattern or
the presentation pattern. In the later case the mediator becomes a
kind of controller for your view.</p>
<p>Mediators and View controllers are an area of healthy debate in
RL :)</p>
<p>So - if you have a purist kind of mediator, there's no need to
do anything. If you have a view-controller kind of mediator, you'd
probably want to switch to manual mediation to avoid re-running
expensive code or putting brittle conditionals into every
mediator.</p>
<p>I'm not sure I've said anything different here though... ?
Hmm... maybe you had a different question?</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/34453412010-11-29T15:37:27Z2010-11-29T15:37:27ZMediator onRegister called more than once, with view's "excludeFrom".<div><p>Thanks, yes that makes sense... Your answer is what I was
looking for: no unique way of thinking!</p>
<p>Since my views are supposed to be added and removed from the
stage but not very frequently I think I should stick with the
onRegister+onRemove logic, looks a look cleaner to me.</p>
<p>Thanks again!</p></div>Quentin