tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/271-multiple-listenersRobotlegs: Discussion 2012-07-17T15:50:23Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/57477082011-03-04T22:13:22Z2011-03-04T22:13:22ZMultiple Listeners<div><p>Hi,</p>
<p>is that event a custom one? Did you override the clone
method?</p></div>krasimirtag:robotlegs.tenderapp.com,2009-10-18:Comment/57477082011-03-04T22:17:12Z2011-03-04T22:17:15ZMultiple Listeners<div><p>Hmm. I extended event and overrode clone at that level, but I
subclassed that event and didn't override clone in the subclasses.
Still, it's strange that one mediator would work over the other.
overriding clone in the subclasses makes them both work.</p></div>Tylertag:robotlegs.tenderapp.com,2009-10-18:Comment/57477082011-03-05T07:25:06Z2011-03-05T07:25:06ZMultiple Listeners<div><p>Yep, all Event subclasses need to override clone, even
subclasses of subclasses. The reason why the first listening
mediator does pick it up, is because it receives the "original"
dispatched event with all it's properties filled in. After that the
event is cloned and the clone's properties are empty, that's why
the next listeners don't receive it.<br>
Now, WHY events get cloned instead of simply get passed through, I
don't know. It seems like a lot of overhead especially for
something as essential and common as events.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/57477082011-03-05T14:06:19Z2011-03-05T14:06:19ZMultiple Listeners<div><p>That's not entirely true. You need to implement clone if and
only if<br>
you need to preserve some custom properties on your subclass. If
you<br>
don't need to do that, you also don't need to override clone.</p>
<p>Also, the event isn't cloned between two mediators receiving
it.<br>
Cloning only happens on redispatch, which doesn't happen if you
just<br>
use Mediator#dispatch.</p>
<p>I suspect what's really going on is that the mediator not
receiving<br>
the event simply doesn't yet exist at the time the event is<br>
dispatched. To test that, you should add logging to both the
event<br>
dispatching and the mediator creating and see in which order the
log<br>
messages appear.</p>
<p>If this assumption turns out to be correct, you should check
out<br>
Stray's RelaxedEventMap: It's specifically tailored to help out
with<br>
situations like this:<br>
<a href=
"https://github.com/Stray/robotlegs-utilities-RelaxedEventMap">https://github.com/Stray/robotlegs-utilities-RelaxedEventMap</a></p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/57477082011-03-05T15:43:14Z2011-03-05T15:43:15ZMultiple Listeners<div><p>@tschneidereit - The mediators were all created and present at
the time. Everything gets time to wire up because this event is
dispatch in reaction to a user event. It was never hitting the
third mediator until I overrode clone in the sublcass.</p></div>Tylertag:robotlegs.tenderapp.com,2009-10-18:Comment/57477082011-03-05T15:50:07Z2011-03-05T15:50:07ZMultiple Listeners<div><p>Interesting, thanks for following up!</p>
<p>I think I'll create a unit test just to investigate what's going
on,<br>
as I don't see any reason for that to happen in the code-base.</p></div>Till Schneidereit