tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/528-one-service-for-multiple-viewsRobotlegs: Discussion 2011-05-25T08:34:07Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/71020762011-05-09T12:39:49Z2011-05-09T12:39:49ZOne service for multiple views<div><p>Store the information returned by the service in a model. Once
the data is saved there just dispatch an event DATA_RECEIVED or
something like that. Catch this event with your mediator.</p></div>krasimirtag:robotlegs.tenderapp.com,2009-10-18:Comment/71020762011-05-09T12:46:26Z2011-05-18T07:48:07ZOne service for multiple views<div><p>This is done for the first view with a model and and mediator,
problem is that i can't seem to get the second view to catch the
event for the service since it is called in the first mediator.</p></div>eldamartag:robotlegs.tenderapp.com,2009-10-18:Comment/71020762011-05-09T12:48:31Z2011-05-09T12:48:31ZOne service for multiple views<div><p>What if you re-dispatch the event, fired by the service, on the
event bus. I.e. by using the global eventDispatcher.</p></div>krasimirtag:robotlegs.tenderapp.com,2009-10-18:Comment/71020762011-05-09T12:59:06Z2011-05-18T07:48:08ZOne service for multiple views<div><p>Ah, my problem seems to be that the second view is not
registered once the event is dispatched. it's in a viewstacked
tabbed windows so its only registered once visible.</p>
<p>Maby i can read allready loaded calls in some way once
registered. thanks for the global eventDispatcher to, didn't know
about that thing.</p></div>eldamartag:robotlegs.tenderapp.com,2009-10-18:Comment/71020762011-05-09T13:09:57Z2011-05-09T13:09:57ZOne service for multiple views<div><p>You are welcome :) I really like to use the event bus. In your
case you can dispatch events for requesting and sending data. I.e.
the mediators dispatch events notifying that they need data. You
can map this events to a command that checks if the model has
required information. If yes then dispatch a new event with the
data as payload. If not then call a service to fill the model.</p></div>krasimirtag:robotlegs.tenderapp.com,2009-10-18:Comment/71020762011-05-10T17:32:45Z2011-05-10T17:33:46ZOne service for multiple views<div><p>There are 2 common scenarios:<br>
1/ either make sure the service has done it's loading
<em>before</em> the views are instantiated, so they can both
receive the data from the model containing the data.<br>
2/ let each mediator request the data, if the data isn't already in
the model the service gets called, the data gets stored and the
data is returned to the requesting mediator.<br>
When the second mediator requests the data it gets pulled out of
the model and served.</p>
<p>Obviously both scenarios would use commands to call services,
store the data in the model and serve the data to the mediators.
The above conundrum is exactly one of the reasons why it's best not
to let mediators access services and models directly.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/71020762011-05-11T08:32:11Z2011-05-11T08:32:11ZOne service for multiple views<div><p>Folk are spot on - the only option they didn't discuss is the
RelaxedEventMap:</p>
<p><a href=
"https://github.com/Stray/robotlegs-utilities-RelaxedEventMap">https://github.com/Stray/robotlegs-utilities-RelaxedEventMap</a></p>
<p>Stray</p></div>Stray