Home → Robotlegs 2 →

Module PopUp Behavior Bug

• Edit

mbarjawi

27 Jun, 2013 09:11 PM

Hello Team,

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.

This is the situation:

• I have a behavior that is mapped in the main application context.
• I have a module with a different context.
• Inside the module, I open a popup window.
• 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).

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:

• Behavior "IBehaviorTwo" is mapped in the main application. This behavior displays a message on Initialized and another on Destroyed.
• 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.
• 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.
• If you try and place the following line in SubAppModule.mxml: <views:SubHelloWorldView/> 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.

Thanks for your help,
Barjawi

• TestInjections.rar 2.8 MB

1. Support Staff 1 Posted by Ondina D.F. on 27 Jun, 2013 10:28 PM

   

   Hi Barjawi,

   I'll take a look at your example, and let you know about my findings tomorrow (it's getting late here)
   Have you added the popup to the viewManager ?
   Ondina

   • Edit

2. 2 Posted by mbarjawi on 27 Jun, 2013 10:54 PM

   

   Hi Ondina,

   Yes I did. This is how the ShowSubDialogCommand class looks like:

   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 );
       }
   }
   

   Thank you for your help,

   • Edit

3. Support Staff 3 Posted by Ondina D.F. on 28 Jun, 2013 11:47 AM

   

   Indeed the mappings from shell aren’t inherited by the module’s popup.

   I can confirm that adding SubHelloWorldView directly to the Module works just fine, the mediator gets created.

   The following work:

   • all 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):

   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 );
   

   • map IBehaviorTwo in the sub-context config (SubAppConfig) as well:

   SubAppConfig:
   
   signalCommandMap.map(ShowSubDialog).toCommand(ShowSubDialogCommand);
   mediatorMap.map(ISubBehaviorOne).toMediator(SubBehaviorOneMediator);
   
   mediatorMap.map(IBehaviorTwo).toMediator(BehaviorTwoMediator);
   

   AppConfig:
   
   injector.map( IFlexModuleFactory ).toValue( TestInjections( FlexGlobals.topLevelApplication ).moduleFactory );
   signalCommandMap.map( ShowDialog ).toCommand( ShowDialogCommand );
   mediatorMap.map( IBehaviorOne ).toMediator( BehaviorOneMediator );
   mediatorMap.map( IBehaviorTwo ).toMediator( BehaviorTwoMediator );
   

   That made me think that the viewManager got “lost” along the way somehow ;) That’s why I tried this:

   • your original mappings, and in ShowSubDialogCommand, instead of injecting the viewManager, I :

   viewManager = injector.parent.getInstance(IViewManager);
   

   The injected viewManager is the one provided by the sub-context.
   injector.parent.getInstance is the shell’s context viewManager.

   Not sure yet, why the viewManager is behaving like this in a module’s context. I’ll try some more things…

   • Edit

4. Support Staff 4 Posted by Ondina D.F. on 29 Jun, 2013 08:07 AM

   

   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.

   Hopefully, Shaun will say more about this.

   • Edit

5. Support Staff 5 Posted by Ondina D.F. on 29 Jun, 2013 02:11 PM

   

   EDIT:

   The ViewManager/StageCrawler of the subcontext can’t ‘see’ the display objects added to the display list of
   the parent context view.

   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…

   I think mapping the view with the viewProcessorMap can solve the problem
   I need to try it out.
   Of course, it doesn’t work since it’s the same logic as with the MediatorMap. The mappings aren’t inherited.

   • Edit

6. Support Staff 6 Posted by Shaun Smith on 29 Jun, 2013 04:54 PM

   

   Hi. You need to map IBehaviorTwo to BehaviorTwoMediator in SubAppConfig if you want this to work.

   Child Contexts do not inherit mediator or command mappings, they only inherit dependency mappings (when no such mapping exists in the child).

   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 its Display List.

   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 ISubBehaviorOne to SubBehaviorOneMediator, but has no mappings for IBehaviorTwo.

   I hope that helps to explain what's going on.

   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 ShowSubDialogCommand by digging out the parent context's IViewManager and adding the popup to it. I would be careful though, you'll be mixing scopes and things could get quite confusing indeed!

   • Edit

7. Support Staff 7 Posted by Shaun Smith on 29 Jun, 2013 05:04 PM

   

   BTW, here's how you could allow both the shell and the module to process the popup:

   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 );
     }
   }
   

   • Edit

8. Support Staff 8 Posted by Ondina D.F. on 29 Jun, 2013 05:47 PM

   

   @Shaun Nice solution!

   • Edit

9. 9 Posted by mbarjawi on 29 Jun, 2013 07:04 PM

   

   Thank you @Ondina and @Shaun for your hard work.

   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.

   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,

   Thanks

   • Edit

10. Support Staff 10 Posted by Shaun Smith on 29 Jun, 2013 07:36 PM

    

    I hope we can, at some point, have a complete documentation

    Yeh.. I know.. it's just hard to find the time these days.

    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

    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.

    • Edit

11. 11 Posted by mbarjawi on 30 Jun, 2013 01:50 AM

    

    Thank you so much. I'll just use your last suggestion. I think its cleaner and better.

    • Edit

12. mbarjawi closed this discussion on 30 Jun, 2013 01:50 AM.