tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/9277-modular-popupsRobotlegs: Discussion 2014-02-03T14:06:40Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/311957852014-01-20T12:23:28Z2014-01-20T12:29:38Zmodular popups<div><p>Hello,</p>
<p>I've read the posts related to this one. You're citing Beau's
posts, so I think you've seen my modular example on github, right?
I'm loading a module in a popup, where only the module has its own
context. The popup is just a container created in the parent
context. There are no memory leaks in my example.<br>
If I understand correctly, you create a context for the popup,
which then loads a module with its own context.<br>
The problem with a popup that has its own context is that when you
remove the popup from the stage you need to let the
<strong>same</strong> viewManager that has added it through<br>
viewManager.addContainer(titleWindowInstance); remove the
titleWindowInstance.</p>
<p>And that viewManager is the <strong>parent context's
viewManager</strong>!!</p>
<p>In this post <a href=
"http://knowledge.robotlegs.org/discussions/robotlegs-2/7627-modular-popups-round-2">
http://knowledge.robotlegs.org/discussions/robotlegs-2/7627-modular...</a>
, Beau is trying to remove the titleWindowInstance in the command
that has created the popup. That won't work, because the command is
already "gone" by the time the popup gets closed. Thus, the
titleWindowInstance won't get gc-ed.</p>
<p>You've tried to cache the popup to remedy this situation (memory
leaks). But, in my opinion, that's not really a good idea. It makes
things unnecessarily complicated.</p>
<p>Can you tell me, why do you need a context for the popup? Just
curious.</p>
<p>If you want to keep your setup, with a context for your popup, I
suggest to let it be destroyed when the popup leaves the stage. I
don't see any advantages in using a cache. Can you convince me of
the contrary?;)</p>
<p>So, if you decide to destroy popup's context, you have a few
choices:</p>
<ul>
<li>you create your popup inside a mediator in the parent context
and add something like this:
titleWindowInstance.addEventListener(CloseEvent.CLOSE,
onTitleWindowClose);</li>
</ul>
<p>Inside of onTitleWindowClose:<br>
viewManager.removeContainer(event.currentTarget as
DisplayObjectContainer);</p>
<ul>
<li>you create a named mapping for the IViewManager in your parent
context, and inject the viewManager into your parent-context
mediator or command that's creating the popup and into popup's
mediator:</li>
</ul>
<p>[Inject (name="parentViewManager")] public var
viewManager:IViewManager;</p>
<p>You add the titleWindowInstance to the shared viewManager in
your parent context (mediator or command) and remove it from the
shared viewManager inside of the destroy() method of your popup's
mediator.<br>
This way the popup view will be destroyed, and so will be its
mediator and context. No memory leaks!<br>
If it's confusing, let me know, and I'll try to give you more
details or to explain it better.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/311957852014-01-20T21:10:33Z2014-01-20T21:10:33Zmodular popups<div><p>The popup module is the checkout process for an ecommerce site.
The reason for using it is to improve application load time. Given
the amount of hassle flex modules are, I'm not sure if the effort
is worthwhile.</p>
<p>The module context holds the checkout model with all the users
checkout data. If we destroyed the context and unloaded the module
when the popup is closed, upon reopening, the user would have to
reenter information.</p>
<p>I suppose we could keep the checkout data model in the main
application instead of the module and destroy the module when it's
closed, but then you pay the cost of loading the module every time
it is opened.</p>
<p>We have a separate module for an account details popup that we
do want the module to be unloaded and the context destroyed when
the popup is closed and we do have this working correctly.</p></div>barrusjtag:robotlegs.tenderapp.com,2009-10-18:Comment/311957852014-01-21T08:47:15Z2014-01-21T08:47:15Zmodular popups<div><p>If I needed to keep the popup's context alive, I wouldn't close
it on CloseEvent.CLOSE. I would just change its visibility, false
on closing, true on opening, and add another mechanism for closing
and removing it from stage.<br>
Would it work for you?</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/311957852014-01-21T12:12:14Z2014-01-21T12:12:14Zmodular popups<div><p>I've tried out your setup with a popup (TitleWindow) context
that doesn't install the StageSync Extension.<br>
In order to have a mediator for the popup, I had to map the popup
view to its mediator in the shell's context.<br>
I created the popup in a shell's mediator, where I also injected
the IMediatorMap.</p>
<pre>
<code>[Inject]
public var mediatorMap:IMediatorMap;
...
private var titleWindowInstance:PopupView;//a TitleWindow
private function onLoadPopupWithContext(event:ModulesLoaderEvent):void
{
if(titleWindowInstance!=null)
{
PopUpManager.addPopUp(titleWindowInstance, FlexGlobals.topLevelApplication as DisplayObject);
mediatorMap.mediate(titleWindowInstance);
return;
}
...
//here, create the popup, add it to the viewManager, etc</code>
</pre>
<p>That works just for the popup, meaning the context won't be
destroyed and you can re-mediate the popup. I did not load a module
the way you did, though.<br>
I still think that you are making your life much harder than it
needs to be by adding a module to the PopUpManager :)<br>
As you said, Modules are problematic anyway. Combined with the
PopUpManager they become a real pain...<br>
I'm curious to know, why do you think the way I loaded the module
and presented it in a TitleWindow (in my example) is not good. As I
said in my previous post, you could just hide the TitleWindow, so
the module's context won't get destroyed. Do you really need the
functionality of a popup (managed by the PopUpManager), or could
you use another container, like a Panel, to present your
module?</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/311957852014-01-21T13:42:30Z2014-01-21T13:42:30Zmodular popups<div><p>I've investigated your scenario even further. I've created a
module the way you did.<br>
Actually, things are easier than I thought.<br>
I've created the context inside creationCompleteHandler of the
module:</p>
<pre>
<code>removeEventListener(FlexEvent.CREATION_COMPLETE, creationCompleteHandler);
_robotlegsContext = new RobotlegsContext(this);</code>
</pre>
<p>The RobotlegsContext:</p>
<pre>
<code>context = new Context()
.install(CustomBundle)//whithout StageSyncExtension
.configure(MediatorsConfig, ModuleConnectorConfig)
.configure(new ContextView(view));
context.initialize();//!!!!!</code>
</pre>
<p>I've forced context initialization!!</p>
<p>MediatorsConfig:</p>
<pre>
<code>mediatorMap.map(IModuleView).toMediator(SomeModuleMediator).autoRemove(false);</code>
</pre>
<p>I've set autoRemove to false !! That's all it takes, and as far
as I can see, it works well, no memory leaks...<br>
I hope that helps.</p></div>Ondina D.F.