tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/12901-one-event-multiple-commandsRobotlegs: Discussion 2015-07-01T06:42:20Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/367960582015-05-11T11:07:32Z2015-05-11T11:07:32Zone event, multiple commands<div><p>Hi,</p>
<p>Of course it is a good practice to have classes following the
SRP (single responsibility principle), so having 2 commands for 2
different actions is perfect, especially if you need to trigger
those commands separately from different parts of your application.
But, in this case, you'd have to use 2 different event types to
trigger the 2 commands and better names for your commands and event
types.</p>
<p>I'm assuming that MarkItemAsOpened is a command that accesses a
model, right?<br>
MarkItemAsOpened is too generic of a name. Which item should be
marked? What if there are several lists in your app?<br>
OpenItemAndMarkItAsOpenedCommand is also not a good name.<br>
But, I guess that the names you used were just an example for the
sake of the discussion and you're not going to use them in your
real code.</p>
<p>Anyway, let's say that your list is a users list inside of a
UsersListView. When a list item is selected you want to update the
UsersModel, setting the selected item, and then you want to open a
UserDetailsView with some data loaded from a server.</p>
<p>The event that you are dispatching from view would be a
UserEvent.USER_SELECTED. The UsersListMediator would redispatch it
and trigger an UpdateUsersCommand that would access a
UsersModel.</p>
<p>Another event type would be UserEvent.LOAD_USER_REQUESTED that
would trigger a LoadUserCommand, where you'd access a
UserService.<br>
The names of the view, mediator, event, model, service and
commands, are now representing a functional unit in your
application.</p>
<p>Where you dispatch UserEvent.LOAD_USER_REQUESTED is up to
you.<br>
If after updating the model you'd <strong>always</strong> want to
load user's data, you could dispatch the LOAD_USER_REQUESTED event
from within the UpdateUsersCommand.</p>
<p>There are cases where accessing the model and then the service
within the same command wouldn't be such a big violation of the
SRP. If you're sure that user selected will always be followed by a
load user details, then you can simply do that inside of the same
command.<br>
Maybe you could have a CreateUserCommand, a LoadUserCommand, an
SaveUserCommand, and a DeleteUserCommand, etc. Each command
accesses the UserModel before calling the service to perform the
desired action. So, each command would be injected with an
IUserModel and with an IUserService and would call the appropriate
methods on these classes.</p>
<p>But, if you'd need to dispatch an event to trigger a command
that would access a service from several parts of your application,
the above wouldn't be a good solution, because maybe you won't
always want to also update the model before accessing the
service.</p>
<p>If you're not sure what to do, start with having separate
commands, one (or as many as needed) for manipulating the model and
other(s) for calling the service.<br>
After gaining more experience with robotlegs you'll know when you
can deviate a little from the rules ;)</p>
<p>Hope this helps<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/367960582015-05-12T06:50:15Z2015-05-12T06:50:57Zone event, multiple commands<div><p>wow! so detailed answer! :)<br>
thank Ondina!</p>
<p>what I eventually did:</p>
<p>1) CustomItemRenderer dispatch</p>
<p>new ListEvent(ListEvent.SELECTED, data)</p>
<p>2) ListViewMediator listen for this event, and redispatch it</p>
<p>new ListEvent(ListEvent.SELECTED, data)</p>
<p>3) OpenExternalURLCommand is executed and Service is called.</p>
<p>4) Service do both jobs:</p>
<ul>
<li>open external link</li>
<li>dispatch new ItemEvent(ListItemEvent.OPENED, data);</li>
</ul>
<p>5) MarkItemAsOpened is called.</p>
<p>-Model is accessed, and the item is marked as "opened"</p>
<p>-event is dispatched: new ListEvent(ListEvent.UPDATED,
item);</p>
<p>6) ListViewMediator is informed and update its list</p>
<p>What do you think?</p></div>hellotag:robotlegs.tenderapp.com,2009-10-18:Comment/367960582015-05-12T08:05:40Z2015-05-12T08:05:40Zone event, multiple commands<div><p>You're welcome:)</p>
<p>I think that the workflow you described is perfect. The only
thing I'd do a bit differently would be the naming of the event
types, namely I'd be more specific: instead of SELECTED I'd say
ITEM_SELECTED , but that's just a matter of preferences.<br>
Also instead of ListEvent I'd use a slightly different name to
avoid possible confusions with the already existing
mx.events.ListEvent.</p></div>Ondina D.F.