tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/3608-module-popup-behavior-bugRobotlegs: Discussion 2018-10-18T16:35:49Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-27T21:11:11Z2013-06-27T21:11:11ZModule PopUp Behavior Bug<div><p>Hello Team,</p>
<p>I am having some trouble in my robotlegs application. Not sure
if it is my mistake or a bug in Robotlegs, your feedback will be
highly appreciated as always.</p>
<p>This is the situation:</p>
<ul>
<li>I have a behavior that is mapped in the main application
context.</li>
<li>I have a module with a different context.</li>
<li>Inside the module, I open a popup window.</li>
<li>If this popup window implements the behavior that is mapped in
the parent context... the behavior simply doesn't work (the
software doesn't get to the initialized method inside the
behavior).</li>
</ul>
<p>I have created a sample application to demonstrate this problem.
Please take a look. If you have any question about how the demo
works please let me know. In simple terms:</p>
<ul>
<li>Behavior "IBehaviorTwo" is mapped in the main application. This
behavior displays a message on Initialized and another on
Destroyed.</li>
<li>If you click the button on the main application "Show Dialog".
A dialog which implements IBehaviorTwo will open. This dialog
exists in the main application's context. The alerts will show
fine.</li>
<li>If you click on "Show Sub Dialog", a dialog in the module's
context that also implements the same behavior will open. No alert
messages will show.</li>
<li>If you try and place the following line in SubAppModule.mxml:
<code><views:SubHelloWorldView/></code> which basically adds
the view that exists in the module's context and that implements
IBehaviorTwo directly into the Module's mxml page... you will see
the alerts fine. This indicates that the problem is in having it as
a popup.</li>
</ul>
<p>Thanks for your help,<br>
Barjawi</p></div>mbarjawitag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-27T22:28:27Z2013-06-27T22:28:27ZModule PopUp Behavior Bug<div><p>Hi Barjawi,</p>
<p>I'll take a look at your example, and let you know about my
findings tomorrow (it's getting late here)<br>
Have you added the popup to the viewManager ?<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-27T22:54:35Z2013-06-27T22:54:35ZModule PopUp Behavior Bug<div><p>Hi Ondina,</p>
<p>Yes I did. This is how the ShowSubDialogCommand class looks
like:</p>
<pre>
<code>public class ShowSubDialogCommand
{
[Inject]
public var moduleFactory:IFlexModuleFactory;
[Inject]
public var viewManager:IViewManager;
public function execute():void
{
var dialog:MySubDialog = new MySubDialog();
viewManager.addContainer( dialog );
PopUpManager.addPopUp( dialog, FlexGlobals.topLevelApplication as DisplayObject, true, null, moduleFactory );
PopUpManager.centerPopUp( dialog );
}
}</code>
</pre>
<p>Thank you for your help,</p></div>mbarjawitag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-28T11:47:32Z2013-06-28T11:47:32ZModule PopUp Behavior Bug<div><p>Indeed the mappings from shell aren’t inherited by the
module’s popup.</p>
<p>I can confirm that adding SubHelloWorldView directly to the
Module works just fine, the mediator gets created.</p>
<p>The following work:</p>
<ul>
<li><strong>all</strong> sub-context mappings in the shell’s
config (AppConfig), but it’s not something we want to have
(of course, in this case you don’t need the
SubAppConfig):</li>
</ul>
<pre>
<code>injector.map( IFlexModuleFactory ).toValue( TestInjections( FlexGlobals.topLevelApplication ).moduleFactory );
signalCommandMap.map( ShowDialog ).toCommand( ShowDialogCommand );
mediatorMap.map( IBehaviorOne ).toMediator( BehaviorOneMediator );
mediatorMap.map( IBehaviorTwo ).toMediator( BehaviorTwoMediator );
signalCommandMap.map( ShowSubDialog ).toCommand( ShowSubDialogCommand );
mediatorMap.map( ISubBehaviorOne ).toMediator( SubBehaviorOneMediator );</code>
</pre>
<ul>
<li>map IBehaviorTwo in the sub-context config (SubAppConfig) as
well:</li>
</ul>
<pre>
<code>SubAppConfig:
signalCommandMap.map(ShowSubDialog).toCommand(ShowSubDialogCommand);
mediatorMap.map(ISubBehaviorOne).toMediator(SubBehaviorOneMediator);
mediatorMap.map(IBehaviorTwo).toMediator(BehaviorTwoMediator);</code>
</pre>
<pre>
<code>AppConfig:
injector.map( IFlexModuleFactory ).toValue( TestInjections( FlexGlobals.topLevelApplication ).moduleFactory );
signalCommandMap.map( ShowDialog ).toCommand( ShowDialogCommand );
mediatorMap.map( IBehaviorOne ).toMediator( BehaviorOneMediator );
mediatorMap.map( IBehaviorTwo ).toMediator( BehaviorTwoMediator );</code>
</pre>
<p>That made me think that the viewManager got “lost”
along the way somehow ;) That’s why I tried this:</p>
<ul>
<li>your original mappings, and in ShowSubDialogCommand, instead of
injecting the viewManager, I :</li>
</ul>
<pre>
<code>viewManager = injector.parent.getInstance(IViewManager);</code>
</pre>
<p>The injected viewManager is the one provided by the
sub-context.<br>
injector.parent.getInstance is the shell’s context
viewManager.</p>
<p>Not sure yet, why the viewManager is behaving like this in a
module’s context. I’ll try some more things…</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-29T08:07:46Z2013-06-29T08:07:46ZModule PopUp Behavior Bug<div><p>I can’t see how this can be solved other than by using
parent’s viewManager. The parent of the popup-window is the
SystemManger of shell’s context view. The
ViewManager/StageCrawler of the subcontext can’t
‘see’ the display objects added to the display list of
the parent context view.</p>
<p>Hopefully, Shaun will say more about this.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-29T14:11:09Z2013-06-29T14:44:01ZModule PopUp Behavior Bug<div><p>EDIT:</p>
<blockquote>
<p>The ViewManager/StageCrawler of the subcontext can’t
‘see’ the display objects added to the display list
of<br>
the parent context view.</p>
</blockquote>
<p>That was a really bad explanation :P Shame on me. Things are a
bit more complex than that; there are more classes involved in the
process: ViewManager, StageObserver, Containerregistry,
ContainerBinding…</p>
<p>I think mapping the view with the viewProcessorMap can solve the
problem<br>
I need to try it out.<br>
Of course, it doesn’t work since it’s the same logic as
with the MediatorMap. The mappings aren’t inherited.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-29T16:54:06Z2013-06-29T16:54:06ZModule PopUp Behavior Bug<div><p>Hi. You need to map <code>IBehaviorTwo</code> to
<code>BehaviorTwoMediator</code> in <code>SubAppConfig</code> if
you want this to work.</p>
<p>Child Contexts do not inherit mediator or command mappings, they
only inherit dependency mappings (when no such mapping exists in
the child).</p>
<p>The reason that it works when you don't use a popup is that the
shell is catching and processing all views that land on
<strong>its</strong> Display List.</p>
<p>The popup, on the other hand, is landing on a separate display
list that is only being observed by your module's context. That
module currently only maps <code>ISubBehaviorOne</code> to
<code>SubBehaviorOneMediator</code>, but has no mappings for
<code>IBehaviorTwo</code>.</p>
<p>I hope that helps to explain what's going on.</p>
<p>If you actually do want the shell to process items on the new
display list you'll have to tell it to start watching that display
list explicitly in <code>ShowSubDialogCommand</code> by digging out
the parent context's <code>IViewManager</code> and adding the popup
to it. I would be careful though, you'll be mixing scopes and
things could get quite confusing indeed!</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-29T17:04:53Z2013-06-29T17:04:53ZModule PopUp Behavior Bug<div><p>BTW, here's how you could allow both the shell and the module to
process the popup:</p>
<pre>
<code>public class AppConfig implements IConfig
{
// .. as before .. //
[Inject]
public var viewManager:IViewManager;
public function configure():void
{
injector.map(IViewManager, "shellViewManager").toValue(viewManager);
// .. as before .. //
}
}
public class ShowSubDialogCommand
{
// .. as before .. //
[Inject(name="shellViewManager")]
public var shellViewManager:IViewManager;
public function execute():void
{
var dialog:MySubDialog = new MySubDialog();
viewManager.addContainer( dialog );
shellViewManager.addContainer( dialog );
PopUpManager.addPopUp( dialog, FlexGlobals.topLevelApplication as DisplayObject, true, null, moduleFactory );
PopUpManager.centerPopUp( dialog );
}
}</code>
</pre></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-29T17:47:11Z2013-06-29T17:47:11ZModule PopUp Behavior Bug<div><p>@Shaun Nice solution!</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-29T19:04:38Z2013-06-29T19:04:38ZModule PopUp Behavior Bug<div><p>Thank you @Ondina and @Shaun for your hard work.</p>
<p>I didn't know that only the dependencies are automatically
fetched from the parent context if not found in the child context.
I hope we can, at some point, have a complete documentation for
this great framework.. I am sure there are a lot of things that I
still don't know about in this framework.</p>
<p>Do you think it is a good idea to simply map the IBehaviorTwo
behavior in the SubAppConfig? However this way the behavior will be
mapped two times, and the module will be accessing a file outside
of its scope... but this solution works too,</p>
<p>Thanks</p></div>mbarjawitag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-29T19:36:53Z2013-06-29T19:36:53ZModule PopUp Behavior Bug<div><blockquote>
<p>I hope we can, at some point, have a complete documentation</p>
</blockquote>
<p>Yeh.. I know.. it's just hard to find the time these days.</p>
<blockquote>
<p>Do you think it is a good idea to simply map the IBehaviorTwo
behavior in the SubAppConfig? However this way the behavior will be
mapped two times, and the module will be accessing a file outside
of its scope</p>
</blockquote>
<p>Well, that's the thing. By doing this you are mapping it into
the scope of the module. The fact that the behavior file exists
outside of its package structure indicates that perhaps it should
be moved - into a shared lib. I'd recommend that over having view
components that are processed by multiple contexts.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/275262272013-06-30T01:50:37Z2013-06-30T01:50:37ZModule PopUp Behavior Bug<div><p>Thank you so much. I'll just use your last suggestion. I think
its cleaner and better.</p></div>mbarjawi