tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/401-events-push-or-pull-dataRobotlegs: Discussion 2018-10-18T16:35:21Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/46826542011-01-11T17:06:41Z2011-01-11T17:06:41ZEvents. Push or pull data?<div><p>I almost always use push. The model is informing (via an event)
that its state has changed, and offering a new snapshot for
interested parties.</p>
<p>There are two situations where I use pull:</p>
<p>1) Where I have more than one instance of the same view and I
want to only refresh this one (imagine a grid of news stories and
being able to click a 'change' on any one story to get a new one
instead).</p>
<p>2) Where the view arrives after the model has last dispatched a
state change.</p>
<p>In the first case I use a sync-signal request-response pair.
Basically I inject into the mediator a 'request signal' which has
been mapped to a command. The argument for the signal is another
signal, which requires the model's vo as an argument. The mediator
creates this response signal and dispatches it on the request
signal. The command is fired, grabs a vo from the model, and uses
the response signal which the mediator passed as an argument to
send this vo back to the same mediator that fired the request.</p>
<p>In the second case I now use an implementation of the eventMap
which I call the 'relaxedEventMap'. It basically allows you to keep
event history and get the last instance of the event, so that the
view can arrive after the model last updated and pick up the event
that the model last sent. Effectively this is a pull, but the pull
is wrapped in the relaxedEventMap and is being executed in there,
pulling from its history.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/46826542011-01-11T17:23:21Z2011-01-11T17:23:21ZEvents. Push or pull data?<div><p>Thanks for your answer.<br>
"The model is informing (via an event) that its state has changed,
and offering a new snapshot for interested parties" - so do you
create event class for each state?</p></div>Alextag:robotlegs.tenderapp.com,2009-10-18:Comment/46826542011-01-11T17:33:26Z2011-01-11T17:33:26ZEvents. Push or pull data?<div><p>I don't have a golden rule - it's all about what's needed /
appropriate.</p>
<p>If a model is capable of dispatching 2 different kinds of VO
then it's likely that I would create two different event classes,
each of which requires the correct type of VO.</p>
<p>Finding bugs is always slower than just typing code, so if an
extra class is what it takes for the compiler to stop me from
making a stupid mistake then that's fine by me.</p>
<p>However - if the model always dispatches the same type of VO
then chances are that it would only require one event class, though
that event would carry different types.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/46826542011-01-11T22:19:30Z2011-01-11T22:22:43ZEvents. Push or pull data?<div><h2>Can you explain me on an example <a href=
"http://insideria.com/2010/06/an-introduction-to-robotlegs-a-1.html">
http://insideria.com/2010/06/an-introduction-to-robotlegs-a-1.html</a>
?</h2>
<p>private var <em>selected:Author;<br>
public function get selected():Author<br>
{ return</em> selected; }</p>
<p>public function set selected(value:Author):void<br>
{ _selected = value; dispatch(new
SelectedAuthorEvent(SelectedAuthorEvent.SELECTED, selected));</p>
<h2>}</h2>
<p>Would you behave likewise? What if I have another
"selectedField" in that model? Should I create
SelectedFieldAuthorEvent?</p></div>Alextag:robotlegs.tenderapp.com,2009-10-18:Comment/46826542011-01-12T23:24:45Z2011-01-12T23:24:47ZEvents. Push or pull data?<div><p>Personally, I would create an array and push all selected
instances. Then dispatch a unique event with the array as the 2nd
parameter. It's more dynamic and loose-coupled.<br></p></div>Sebastian Servattag:robotlegs.tenderapp.com,2009-10-18:Comment/46826542011-01-13T06:52:27Z2011-01-13T06:52:27ZEvents. Push or pull data?<div><p>selectedField is of another type than Author and have nothing in
common with Author.</p></div>Alex