tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/539-runtime-warning-when-chaining-commands-with-the-commandsignal-extension-part-iiRobotlegs: Discussion 2012-04-05T13:20:07Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/150152952012-04-04T16:20:03Z2012-04-04T16:20:03ZRuntime warning when chaining Commands with the CommandSignal extension Part II<div><p>It's possible that a temporary mapping isn't being unmapped in
time. Could you provide more info? Possibly a stack trace (with
sensitive info stripped out of course)</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/150152952012-04-05T09:01:33Z2012-04-05T09:03:48ZRuntime warning when chaining Commands with the CommandSignal extension Part II<div><p>Hmm, this is what I'm getting:<br>
Warning: Injector already has a mapping for
be.corelio.spoleto.model.vo::DocumentVo|.<br>
If you have overridden this mapping intentionally you can use
"injector.unmap()" prior to your replacement mapping in order to
avoid seeing this message.</p>
<p>Error: Error while removing an injector mapping: No mapping
defined for dependency be.corelio.spoleto.model.vo::DocumentVo|</p>
<pre>
<code>at org.swiftsuspenders::Injector/unmap()[/Users/till/dev/swiftsuspenders/swiftsuspenders/src/org/swiftsuspenders/Injector.as:243]
at org.robotlegs.adapters::SwiftSuspendersInjector/unmap()[/Users/till/dev/robotlegs/robotlegs/src/org/robotlegs/adapters/SwiftSuspendersInjector.as:101]
at org.robotlegs.base::SignalCommandMap/unmapSignalValues()[/Users/passepartout/FlexWorkspace/spoleto/libs/org/robotlegs/base/SignalCommandMap.as:110]
at org.robotlegs.base::SignalCommandMap/routeSignalToCommand()[/Users/passepartout/FlexWorkspace/spoleto/libs/org/robotlegs/base/SignalCommandMap.as:93]
at Function/<anonymous>()[/Users/passepartout/FlexWorkspace/spoleto/libs/org/robotlegs/base/SignalCommandMap.as:35]
at org.osflash.signals::Slot/execute()[C:\Users\Robert\Documents\Flash\OSFlash\signals\as3-signals\src\org\osflash\signals\Slot.as:91]
at org.osflash.signals::OnceSignal/dispatch()[C:\Users\Robert\Documents\Flash\OSFlash\signals\as3-signals\src\org\osflash\signals\OnceSignal.as:125]
at be.corelio.spoleto.view.documents::DocumentsComp/onRequestRefreshDocument()[/Users/passepartout/FlexWorkspace/spoleto/src/be/corelio/spoleto/view/documents/DocumentsComp.as:137]
at org.osflash.signals::Slot/execute()[C:\Users\Robert\Documents\Flash\OSFlash\signals\as3-signals\src\org\osflash\signals\Slot.as:87]
at org.osflash.signals::OnceSignal/dispatch()[C:\Users\Robert\Documents\Flash\OSFlash\signals\as3-signals\src\org\osflash\signals\OnceSignal.as:125]
at Function/<anonymous>()[/Users/passepartout/FlexWorkspace/spoleto/src/be/corelio/spoleto/view/ui/topmenu/TopMenu.as:244]</code>
</pre>
<p>As you can see, i first get the robotlegs warning that the
mapping already exists, and secondly I get the swiftsuspenders
error that it doesn't exist.</p>
<p>Basicly, I want to refresh a jobslist in object documentVo<br>
So what I do:<br>
- refreshDocumentSignal.dispatch( documentsModel.document );</p>
<pre>
<code>-> I should give documentsModel.document as a payload, because it is possible that I need to refresh other documents as well.. otherwise I would've let the command get the document from documentsModel.</code>
</pre>
<ul>
<li>getJobsByQuerySignal.dispatch( document.queryString,
document.query, document ); -> this should get all the jobs from
the server. Even putting dummy data here, like "new DocumentVo()"
crashes the application.</li>
</ul>
<p>It used to work in SwiftSuspenders1.<br>
I'm guessing that it might be looking for a documentVo, because it
probably exists in some temporary mapping, and then tries to get it
from the rest of the mappings, but then notices that this doesn't
exist..<br>
or something like this, no?<br>
It seems like the [inject] functionality in the command might be
confusing him:" should i get the documentVo from my signal, of
should I get it from my mappings".</p>
<p>Sorry if I'm not entirely clear in my explanation.</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/150152952012-04-05T09:10:48Z2012-04-05T09:11:27ZRuntime warning when chaining Commands with the CommandSignal extension Part II<div><p>To recreate the bug, I think all you need to do is:<br>
- create a signal that requires an object SomePayloadObject - in
your mediator: firstSignal.dispatch( new SomePayloadObject() ) - in
the command, triggered by this signal, dispatch another signal that
uses the same type of payload: secondSignal.dispatch( new
SomePayloadObject );</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/150152952012-04-05T09:23:03Z2012-04-05T09:23:03ZRuntime warning when chaining Commands with the CommandSignal extension Part II<div><p>Hi Hans,</p>
<p>Could you try with the version of SCM that is on my fork:</p>
<p><a href=
"https://github.com/Stray/signals-extensions-CommandSignal">https://github.com/Stray/signals-extensions-CommandSignal</a></p>
<p>There was an issue where it became apparent that creating and
executing commands had to happen separately, it sounds like you
have a version from before that.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/150152952012-04-05T09:58:36Z2012-04-05T10:13:51ZRuntime warning when chaining Commands with the CommandSignal extension Part II<div><p>I was already working with the latest version..<br>
Maybe the problem is that the extension is updated for
Swiftsuspenders 1.6, and not for Swiftsuspenders 2..? (as it says
on the messages on <a href=
"https://github.com/Stray/signals-extensions-CommandSignal">https://github.com/Stray/signals-extensions-CommandSignal</a>).</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/150152952012-04-05T10:28:52Z2012-04-05T10:28:52ZRuntime warning when chaining Commands with the CommandSignal extension Part II<div><p>Anyway, I switched back to the regular build (<a href=
"https://github.com/robotlegs/robotlegs-framework/tree/master">https://github.com/robotlegs/robotlegs-framework/tree/master</a>),
which includes SwiftSuspenders 1.6.<br>
Everything works again, but no more optional injections :)</p>
<p>Thx a lot for your help anyway!!</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/150152952012-04-05T11:44:48Z2012-04-05T11:44:48ZRuntime warning when chaining Commands with the CommandSignal extension Part II<div><p>Hey Hans,</p>
<p>sorry for the annoying differences between Swiftsuspenders 1.6
and 2b.<br>
I'm afraid that I might have to can the warnings for most cases
in<br>
Swiftsuspenders 2 anyway: As I have discovered, they make much
less<br>
sense for a fluid API.</p>
<p>I guess that means that 2.0 final will again be warning-free for
your use-case.</p>
<p>cheers,<br>
till</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/150152952012-04-05T12:54:04Z2012-04-05T12:54:04ZRuntime warning when chaining Commands with the CommandSignal extension Part II<div><p>Hey Till,</p>
<p>Cool, I'll keep on eye out for that one. For the moment I'll
just be checking for null objects before i pass them to a signal,
and send empty objects instead.</p>
<p>It's totally awesome how fast and useful you people respond here
every time!<br>
Thanks a lot!<br>
Hans</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/150152952012-04-05T13:20:07Z2012-04-05T13:20:07ZRuntime warning when chaining Commands with the CommandSignal extension Part II<div><p>We try our best, thank you :)</p></div>Till Schneidereit