tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/13221-event-dispatching-rl1-vs-rl2Robotlegs: Discussion 2015-11-30T16:07:44Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/380687442015-09-30T19:34:29Z2015-09-30T19:34:29ZEvent Dispatching RL1 vs RL2<div><p>Hi roelof,</p>
<p>afair it is correct solution make notification from commands,
but i think in anyway it is better to dispatch event with properly
type.</p></div>ishaban.flashtag:robotlegs.tenderapp.com,2009-10-18:Comment/380687442015-09-30T20:54:54Z2015-09-30T20:54:54ZEvent Dispatching RL1 vs RL2<div><p>Hi Roelof,</p>
<p>I can't help you much at the moment, because I'm on
holiday...<br>
In addition to ishaban's answer just a short remark:</p>
<p>rl1 commands looked like so:<br>
<a href="https://github.com/robotlegs/robotlegs-framework/blob/version1/src/org/robotlegs/mvcs/Command.as">
https://github.com/robotlegs/robotlegs-framework/blob/version1/src/...</a></p>
<p>And an Actor class like this:<br>
<a href="https://github.com/robotlegs/robotlegs-framework/blob/version1/src/org/robotlegs/mvcs/Actor.as">
https://github.com/robotlegs/robotlegs-framework/blob/version1/src/...</a></p>
<p>If you like the convenience classes from rl1, you can build your
own command and actor base classes and use them with rl2.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/380687442015-10-01T05:39:36Z2015-10-01T05:39:36ZEvent Dispatching RL1 vs RL2<div><p>Thanks for the reply, I will study the links that you provided
Ondina and take it from there. I just wanted to make sure that I am
on the right track, because there is still a lot I have to learn
about AS3 / Flex / RL</p></div>roeloftag:robotlegs.tenderapp.com,2009-10-18:Comment/380687442015-10-08T15:09:49Z2015-10-08T15:09:49ZEvent Dispatching RL1 vs RL2<div><p>Hi Roelof,</p>
<p>I'm back. Sorry for the delay.</p>
<p>The Command class in rl2 has been intentionally kept
lightweight. All is needed for a Command to be recognized as such
by rl2 is to expose a public method execute().<br>
The rl1 Command had injections for the contextView, injector,
mediatorMap, commandMap and eventDispatcher. Those came in handy,
because we used to do the mappings inside of commands. With rl2
this is no longer necessary. You still can perform your mappings in
commands, if you want. However, a class implementing IConfig is a
much better way of structuring your mappings. You can inject
whatever you need (and only what you need) into such a config
class. This way they are much more lightweight. If you need help
with config classes, let me know. Here just a link to a discussion
about config classes:<br>
<a href="http://knowledge.robotlegs.org/discussions/robotlegs-2/12476-rl2-bootstrap-command-chain#comment_35061717">
http://knowledge.robotlegs.org/discussions/robotlegs-2/12476-rl2-bo...</a></p>
<p>So, as I said in my previous post, you can create a base class
that contains the injections you need.<br>
Just for having access to the shared event dispatcher and to be
able to use the same syntax as with rl1, you can do this:</p>
<pre>
<code>package yourdomain.commons.baseClasses
{
import flash.events.Event;
import flash.events.IEventDispatcher;
public class SharedDispatcher
{
[Inject]
public var eventDispatcher:IEventDispatcher;
protected function dispatch(e:Event):void
{
if (eventDispatcher.hasEventListener(e.type))
eventDispatcher.dispatchEvent(e);
}
}
}</code>
</pre>
<p>Then you can let your commands, models and services extend the
SharedDispatcher.</p>
<p>If you want a rl2-command to behave exactly like a
rl1-command:</p>
<pre>
<code>package yourdomain.commons.baseClasses
{
import flash.events.Event;
import flash.events.IEventDispatcher;
import robotlegs.bender.extensions.eventCommandMap.api.IEventCommandMap;
import robotlegs.bender.extensions.mediatorMap.api.IMediatorMap;
import robotlegs.bender.framework.api.IInjector;
public class BaseCommand
{
[Inject]
public var eventDispatcher:IEventDispatcher;
[Inject]
public var commandMap:IEventCommandMap;
[Inject]
public var injector:IInjector;
[Inject]
public var mediatorMap:IMediatorMap;
public function BaseCommand()
{
}
/**
* @inheritDoc
*/
public function execute():void
{
}
/**
* Dispatch helper method
*
* @param event The <code>Event</code> to dispatch on the <code>IContext</code>'s <code>IEventDispatcher</code>
*/
protected function dispatch(event:Event):Boolean
{
if (eventDispatcher.hasEventListener(event.type))
return eventDispatcher.dispatchEvent(event);
return false;
}
}
}</code>
</pre>
<p>In this case, your commands will have to extend the BaseCommand
and to override the public function execute().<br>
There is no need for a command extending the SharedDispatcher (give
it a name of your choosing) to override execute()!</p>
<p>If you don't want to use base classes, you're right, you have to
inject the event dispatcher into your commands as you did in your
post. Or in a Model or Service for that matter.</p>
<p>Let me know if there is anything else you need help with while
porting your project to rl2.</p>
<p>By the way, can you tell us why are you doing something like
this:</p>
<p>dispatchEvent(new SomeEvent());</p>
<p>I know that this works if you create the custom event class
without a type argument, but mapping such an event to a command
looks kind of weird with "" instead of a type ;)<br>
So, I'm with ishaban on this, I prefer using meaningful event's
types .</p>
<p>Ondina</p></div>Ondina D.F.