tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/262-no-subjectRobotlegs: Discussion 2018-10-18T16:35:16Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/27096892010-08-26T15:17:39Z2010-08-26T15:17:39ZGuidelines for Event / Commands - granularity and ratio<div><p>Here's how I would do it. I'm not advocating that I'm a best<br />
practices master or anything.</p>
<p>I'd have a single command, RequestNewsCommand. I'd execute that by<br />
dispatching an event, like you said. Alternatively, you could cut out<br />
the event and command by having the mediator call the service<br />
directly. On small projects I'd do that, but in larger projects I'd<br />
probably stick to the event+command+service. See Shaun's comment<br />
about when this may or may not be appropriate<br />
(<a href="http://knowledge.robotlegs.org/discussions/questions/258-best-practice-value-lists">http://knowledge.robotlegs.org/discussions/questions/258-best-pract...</a>).</p>
<p>When the service receives a response, I'd probably just have the<br />
service parse the response and drop it on the model on a property like<br />
"news". I usually don't feel it's necessary to have a
response-handling command unless some non-parsing logic needs to take<br />
place and even then I don't use a separate command most of the<br />
time...I just have handlers in the the requesting command.</p>
<p>When the news is set on the model, I generally dispatch events<br />
notifying that the model has changed. For example, I might dispatch a<br />
AccountsModelEvent.NEWS_CHANGED event. "AccountsModel" would be<br />
whatever the model was named. Usually I don't have it carry any<br />
payload but it could. If I wanted to get more granular I could make<br />
it a NewsEvent like you mentioned that carries a specific payload, but<br />
usually I find that to be more than necessary. The mediator watches<br />
for the event and, when heard, picks the news off the model and sets<br />
it into the view. Be careful what you name your events. You<br />
mentioned "NewsEvent.NewsResponse" but in my perspective the model<br />
shouldn't know/care than it's due to any type of response--it just<br />
knows it's news value is changing. Even so, I'm sure there are those<br />
who disagree with how I name my events.</p>
<p>So, in general I would be using one command and two events (one for<br />
initiating the request and one for notifying of a model change). If I<br />
was feeling really lazy or knew my app wasn't going to be large or<br />
complex or that nobody was going to work on it (famous last words) I'd<br />
cut out the request event and command and head straight to the<br />
service. Adding to what Shaun said in the post I mentioned above,<br />
there are other good reasons to go the event+command route. For<br />
example, let's say you had two views that needed to show the same<br />
news. Which one initiates the request for the news? I'd say both<br />
since they should be independent of each others' actions. However,<br />
you probably only want the news to be loaded once. If you went<br />
straight from both mediators to a service, somewhere you're going to<br />
want some logic that makes sure the news only gets requested once. On<br />
the other hand, if you went with an event+command+service then you<br />
could have Robotlegs take care of that for you using the oneshot<br />
parameter when mapping an event to a command. There are things like<br />
this where I'll start out having the mediator calling a service<br />
directly and then later find it's actually simpler using an<br />
event+command+service.</p>
<p>Regarding the various commands you mentioned:<br />
DisplayNewsCommand - I can't see much use for this.<br />
RequestNewsCommand - I'd use this as described above.<br />
HandleNewsResponseCommand - I normally wouldn't use this but know<br />
several people who would.<br />
ClearNewsCommand - I would use this if I needed the functionality.</p>
<p>Hope that helps. I'm interested to see what others say. If anyone<br />
thinks my practices suck I'd be happy to hear about it.</p>
<p>Aaron</p></div>Aaron Hardytag:robotlegs.tenderapp.com,2009-10-18:Comment/27096892010-08-26T15:52:56Z2010-08-26T15:52:56ZGuidelines for Event / Commands - granularity and ratio<div><p>Hi Aaron,</p>
<p>Thank you for taking time to reply to all of my questions!</p>
<p>When you mention the advantages of using event -> command to filter out two news requests, I'm not sure I fully agree that the 'one-shot' parameter is the best way to go - although it does achieve what you say it does.<br />
</p>
<p>My understanding is that it will register the event with a command, then once that event is fired, the mapping is dropped, so you'll only ever get one lot of news (which is what I think you're suggesting), but I would probably want to restrict it to one request at a time and not to be repeated with 30 seconds of the last request, so not one-shot, but perhaps some sort of data in the model that records when it was last requested and then the command could query this and decide to exit the command early, i.e. if </p>
<p>I agree that the model should fire a change event, granularity I think would be refined subject to how much data we are talking about. For example, if news was no more than 10 lines ever, then replacing the entire table every 30 seconds is no problem, but if it's 1,000 rows and we are updating record 99, then it makes sense to update a row instead.</p>
<p>Presumably, it's possible for the mediator to associate a models collection to a binding in code? This way, the first time the update is fired we bind, then subsequently the grid updates automatically - or is this bad practice as we would be short-circuiting the models event and relying on the binding events.</p>
<p>So, if I have my main view with toolbars, should the toolbars click events directly fire events (from the view), or should the mediator register as click listeners and then translate to our events there?</p>
<p>Likewise, when deciding to create a new view (window) from a toolbar button being clicked, should the mediator fire an event to create the view, or should the mediator of the view containing the buttons directly create the new view? (I don't want to over cook the use of events for the sake of it!).</p>
<p>I am looking forward to pushing forward with this framework and will try not to drain too much time from you + others in this community, I do however plan to invest time back in ;-)</p>
<p>Cheers,<br />
Rob.</p></div>robtag:robotlegs.tenderapp.com,2009-10-18:Comment/27096892010-08-26T16:16:20Z2010-08-26T16:16:20ZGuidelines for Event / Commands - granularity and ratio<div><p>Yeah, the whole one-shot thing really just depends on what you're<br />
wanting to do. I wasn't advocating that that's what you should do, I<br />
was just trying to illustrate how events+commands can help take<br />
advantage of Robotlegs features if you have a need for them.</p>
<p>You could have your news property be a collection. When it's first<br />
set, the mediator would push the collection into the view. If you're<br />
using a datagrid or something like that, it should already watch for<br />
when there are items added/removed from the collection so your<br />
mediator wouldn't watch for collection_change events and your model<br />
wouldn't dispatch any particular event unless the collection was<br />
swapped out completely. From your description it sounds like you<br />
understand how that would work and I think that practice is just fine.</p>
<p>Regarding event mapping, I would do something like:</p>
<p>eventMap.mapListener(<br />
</p>
<pre><code> view.loginButton,
MouseEvent.CLICK,
loginButton_clickHandler);</code></pre>
<p>protected function loginButton_clickHandler(event:Event):void<br />
</p>
<pre><code> {
eventDispatcher.dispatchEvent(new LoginEvent(
LoginEvent.LOG_IN,
view.username,
view.password));
}</code></pre>
<p>In response to who should make the new views I would say it depends on<br />
who will be the parent of the new view. The new parent should<br />
probably be the one to make the new view (although popups/windows are<br />
a strange beast). In your case, if the new view will be a child of<br />
the toolbar, then I'd just have the toolbar create the view directly.<br />
However, if the new view is going to be a child of another view I'd<br />
have the mediator dispatch an event. In the case of a popup or window<br />
I'd probably have a command do the popping up or window creation but I<br />
suspect there are a lot of ways this is being done. In the case of<br />
the view being added to some ordinary view elsewhere, the new parent<br />
will watch for the event and create the new child view. You probably<br />
don't want the toolbar or its mediator knowing who the parent is going<br />
to be or caring--I would say it's not it's job.</p>
<p>Aaron</p></div>Aaron Hardy