tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/8377-understanding-signals-parameter-and-command-injectionRobotlegs: Discussion 2013-12-23T09:27:22Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/302283512013-11-27T08:16:33Z2013-11-27T08:16:33ZUnderstanding Signals parameter and Command injection<div><p>I'd strongly recommend against passing primitive types directly
as a<br>
payload in a signal, you should <em>always</em> wrap them in a
value object.</p>
<p>As to your question, if I'm not mistaken the injector should
actually<br>
inject the same value twice, i.e. it should pass the last argument
passed<br>
to the signal constructor into both <code>param1</code> and
<code>param2</code> members of the<br>
command, since behind the scenes it simply iterates over all the
values and<br>
maps them to the injector like this:</p>
<p>injector.map(payloadClasses[i]).toValue(payloadValues[i])</p>
<p>which means it will first map the first signal constructor
argument to<br>
String and then overwrite that mapping with the second signal
constructor<br>
argument.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/302283512013-11-27T08:23:39Z2013-11-27T08:23:39ZUnderstanding Signals parameter and Command injection<div><p>Forgot a part:</p>
<p>The command can receive the signal payload values in two
ways:</p>
<p>1/ into <code>Inject</code>-tagged members (as in your above
example)<br>
2/ as parameters to the <code>execute</code> function.</p>
<p>In 1/ the order of the signal values doesn't matter at all.
E.g:</p>
<pre>
<code>function MySignal(signalFoo:IFoo, signalBar:IBar)</code>
</pre>
<p>will correctly be injected into</p>
<pre>
<code>[Inject]
public var commandBar: IBar;
[Inject]
public var commandFoo: IFoo;</code>
</pre>
<p>However. In 2/ the order <strong>is</strong> of importance</p>
<pre>
<code>public function execute(parameterFoo: IFoo, parameterBar: IBar):void</code>
</pre>
<p>won't throw an error, but this will:</p>
<pre>
<code>public function execute(parameterBar: IBar, parameterFoo: IFoo):void</code>
</pre></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/302283512013-11-27T08:58:15Z2013-11-27T08:58:16ZUnderstanding Signals parameter and Command injection<div><p>Thanks for the detailed explanation. Now I get a better
picture.</p>
<p>Indeed injecting value object is more reasonable though I just
worry if only a simple string is needed, wrapping it up as a value
object seems too much.</p></div>Vicker Leungtag:robotlegs.tenderapp.com,2009-10-18:Comment/302283512013-11-30T08:26:06Z2013-11-30T08:26:06ZUnderstanding Signals parameter and Command injection<div><p>It's not overkill. I try to wrap all my primitive types into
VO's for sake of clarity, readability, better debugging. A
primitive type tells you nothing about the intent/type of the
data.<br>
When dealing with primitive types you need to rely on member and
variable names to know what kind of data your dealing with.<br>
E.g.</p>
<pre>
<code>function login(username:String, password:String):void</code>
</pre>
<p>both parameters are strings and you infer what they represent
through the parameter names. However, for instance the password is
pretty opaque. Is it encrypted? Unencrypted? Unencrypted, yet
salted? Etc. Obviously this is information you could start storing
in the parameter name: <code>unencPassword</code>,
<code>encPassword</code>, etc. but this means that you'll be
sprinkling conversion specific metadata throughout your code. It's
harder to refactor and easier to mess up. (For instance: a method
first received an unencrypted password, gets refactored, but you
forgot to change the parameter name)<br>
However if you use a <code>Password</code> VO it can store both
values, the encrypted and unencrypted, and the client code can use
the value it needs with very little rewriting.</p>
<p>There's another benefit: many times you'll be comparing data and
VO's help you centralize that logic instead of repeating it at
several places.<br>
E.g. you need to compare usernames. At first you wrote a simple
equality check whether two usernames are the same, but later on you
realize you forgot that usernames should be case insensitive.
Probably you'll be adding the additional check in a number of
places, while if you'd had a <code>Username</code> VO with a
<code>isEqual</code> method to begin with, you'd be modifying the
<code>isEqual</code> method and that's it.</p></div>creynders