tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/319-how-to-prevent-injections-into-module-loader-with-new-applicationdomain-that-is-added-to-the-shells-contextviewRobotlegs: Discussion 2013-04-28T09:55:29Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/73276822011-05-25T08:10:42Z2011-05-25T08:10:42ZHow to prevent injections into module (Loader with new ApplicationDomain) that is added to the shell's contextView?<div><p>Hi Pavel,</p>
<p>did you get this figured out?</p>
<p>One option would be to use the old-fashioned original version of
the modular utilities - these don't use the child injectors, and
don't inject from the shell to the loaded modules.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/73276822011-05-25T10:11:15Z2011-05-25T10:11:15ZHow to prevent injections into module (Loader with new ApplicationDomain) that is added to the shell's contextView?<div><p>Nope, haven't figured out. I don't think modular utilities is
something for me since I just load external SWFs in a new
ApplicationDomain (it's not modules in RL concept, but just
external RL-powered SWFs that should not be affected by shell's
injector). So it's seems more like SwiftSuspenders question
again.</p></div>pavel.fljottag:robotlegs.tenderapp.com,2009-10-18:Comment/73276822011-05-25T10:39:27Z2011-05-25T10:39:27ZHow to prevent injections into module (Loader with new ApplicationDomain) that is added to the shell's contextView?<div><p>Hi Pavel,</p>
<p>if you add something to <em>this</em> contextView then the
mediatorMap within that contextView will respond, and use the local
injector, with the original appDomain, to try to fulfil the
injections.</p>
<p>Is there some way you can separate the contextViews? for
example:</p>
<pre>
<code>stage view
-> child container
-> main context view
-> child container
-> loaded swf context view</code>
</pre>
<p>By container I just mean a sprite - doesn't have to be flex.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/73276822011-05-25T10:44:51Z2011-05-25T10:44:51ZHow to prevent injections into module (Loader with new ApplicationDomain) that is added to the shell's contextView?<div><p>Yea, that's how I do now (as mentioned in the last paragraph of
the original question), but doesn't seems like a perfect way.</p></div>pavel.fljottag:robotlegs.tenderapp.com,2009-10-18:Comment/73276822011-05-25T10:49:57Z2011-05-25T10:49:57ZHow to prevent injections into module (Loader with new ApplicationDomain) that is added to the shell's contextView?<div><p>Hi Pavel,</p>
<p>well, you do have a multi-context app - and there are 3
solutions for that - one is the new modular utils, another is the
old modular utils, and the 3rd is to keep your contexts totally
separate - you've gone for the 3rd.</p>
<p>I'll see if Till has any more thoughts about it, but I don't see
a problem with what you're doing. The concept of 'contextView'
means 'the view used for this context' - not just 'main view'. So
it does have implications - which you've got a good work around
for.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/73276822011-05-25T11:45:00Z2011-05-25T11:45:00ZHow to prevent injections into module (Loader with new ApplicationDomain) that is added to the shell's contextView?<div><p>Stray, I still think it's an issue. Because I could really need
to put my external swf somewhere into shell's context view, but
still preserve it as a completely separate piece (not having any
injections into it). So some (SOME!) sort of
injector.preventFromInjection(view:DisplayObject) could make the
trick... So unlike most "modular" topics I want to get non-modular
behavior when loading the module =)<br>
Or maybe I miss something regarding modular utilities?</p></div>pavel.fljottag:robotlegs.tenderapp.com,2009-10-18:Comment/73276822011-05-25T12:00:21Z2011-05-25T12:00:21ZHow to prevent injections into module (Loader with new ApplicationDomain) that is added to the shell's contextView?<div><p>I'm hoping Till will wade in here - he's much more aware of
these kinds of intricacies than I am.</p>
<p>The issue I think though is that you must have the same view
class mapped in your shell as in your child views, yes? In the
mediator?</p>
<p>So - you have something like this in both the parent context and
the loaded-swf context:</p>
<pre>
<code>mediatorMap.mapView(SomeView, SomeViewMediator); (or view map equivalent)</code>
</pre>
<p>The mediatorMap waits for ADDED_TO_STAGE events on the
contextView - so if your child views are inside your contextView,
and you add something to the stage, ALL context views that this
element is inside of will try to create a mediator for it - because
all those contextViews will fire the ADDED_TO_STAGE event. Perhaps?
Unless I'm wrong about the way this event works in this
scenario.</p>
<p>If it is that the event is being fired in every parent in the
chain, I'm not really sure there is anything that can be done about
that in terms of the robotlegs side - there's no way for it
interrogate the whole container (parent) chain to check for nested
contextViews, because each mediatorMap is ignorant of the others,
and a contextView is only an instance of DisplayObjectContainer, it
has no special properties in terms of extending a class etc.</p>
<p>So - how could any one contextView/mediatorMap know that it's
not really supposed to mediate/map this class? Injection will only
happen on mediators, commands and items marked for injection - so
the example you cite (with the swf not having injections) wouldn't
be a problem.</p>
<p>Did I miss something? If I've got it wrong that you've got a
view of the same type mapped to the mediatorMap in both your shell
and your loaded swf then I could be way off here!</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/73276822011-05-25T13:09:34Z2011-05-25T13:09:34ZHow to prevent injections into module (Loader with new ApplicationDomain) that is added to the shell's contextView?<div><p>Nope, you didn't miss anything: Your description of what's going
on<br>
and why is spot on.</p>
<p>The only thing I might add is that not only is this behavior
hard to<br>
change from a technical point of view, it's also desirable in
some<br>
cases.</p>
<p>I've been thinking about how to optimize the case of nested<br>
contextViews for quite some time now and one idea I've had is to
let<br>
mediatorMaps try to combine their ADDED_TO_STAGE/
REMOVED_FROM_STAGE<br>
listeners in the outermost contextView. That would allow for
the<br>
creation of more complex behavior such as the innermost
mediatorMap<br>
declaring a view as "handled" and thus stopping outer contexts
from<br>
trying to map the view, too. I'm not sure if the advantages are
worth<br>
the increased complexity, though.</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/73276822011-05-28T23:14:45Z2011-05-28T23:14:45ZHow to prevent injections into module (Loader with new ApplicationDomain) that is added to the shell's contextView?<div><p>OK, here's proof of concept that actually worked as desired:</p>
<p>ShellContext extends Context/SignalContext:</p>
<pre>
<code>override protected function get viewMap():IViewMap
{
return _viewMap ||= new ShellViewMap(contextView, injector);
}</code>
</pre>
<p>ShellViewMap extends ViewMap:</p>
<pre>
<code>override protected function onViewAdded(e:Event):void
{
if (isValidView(e.target as DisplayObject))
{
super.onViewAdded(e);
}
}
private function isValidView(target:DisplayObject):Boolean
{
var valid:Boolean = true;
while (target.parent)
{
if (target is ModuleView)
{
return false;
}
target = target.parent;
}
return valid;
}</code>
</pre>
<p>Not the most optimal & flexible code, but just to make an
example. This allows me to add external RL module (loaded swf into
new ApplicationDomain) into main contextView WITHOUT injecting
anything into it, so two RL contexts becomes completely
independent... well looks like =) haven't tested in all the
possible ways. Now. Questions is — is it worth to add
something into ModularUtilities (which is the last and popular
one?) to implement this workflow?</p></div>pavel.fljottag:robotlegs.tenderapp.com,2009-10-18:Comment/73276822011-05-29T14:46:07Z2011-05-29T14:46:07ZHow to prevent injections into module (Loader with new ApplicationDomain) that is added to the shell's contextView?<div><p>At least in the implementation you give, this is bound to be<br>
excessively slow: The loop in isValidView will be invoked for each
and<br>
every DisplayObject hitting the display list anywhere below the<br>
contextView. What you could do instead is to at least check if
the<br>
ShellViewMap itself is even interested in the DisplayObject
being<br>
added. If that is not the case, then you don't need to invoke<br>
isValidView at all.</p>
<p>Other than that: Sure, this approach works. I'd be hesitant to
add it<br>
to the ModularUtilities, though, as it is very specialized and
only<br>
works for exactly you use-case, while disabling other use-cases
such<br>
as views that should be handled by both the outer as well as the
inner<br>
context.</p>
<p>Adding flexible support for several nested contexts-scenarios is
high<br>
on my list of priorities for RL 2, though.</p></div>Till Schneidereit