tag:robotlegs.tenderapp.com,2009-10-18:/discussions/solutions/1221-mediator-for-flex-dynamic-skin-partRobotlegs: Discussion 2014-04-28T08:11:07Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/324130742014-04-06T09:10:11Z2014-04-06T09:10:11ZMediator for flex Dynamic Skin part<div><p>Hello Duncan,</p>
<p>I've just tried out an example with dynamically added skin parts
(Buttons). It works well on my end. The Buttons are added to a
Group and their mediators are created when they are added to the
stage.</p>
<p>What kind of components are BugContainer and its parents?<br>
Is it possible that your bugs-component or its parent are top-level
components, like Alert, PopUp, Window, etc? If that's the case,
than it will be created 'outside' of the robotlegs-context's scope
and the framework won't be able to automatically create a mediator
for this component. See: <a href=
"http://knowledge.robotlegs.org/kb/reference-mvcs-implementation/how-to-mediate-a-flex-popup">
http://knowledge.robotlegs.org/kb/reference-mvcs-implementation/how...</a></p>
<p>Try out your use case in a simple example where you make sure
that your component and/or its parent are "normal" display objects.
Let us know whether the issues persist or not. If you still have
problems with mediators creation, please attach the example for us
to take a look at it.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/324130742014-04-06T10:03:41Z2014-04-06T10:03:41ZMediator for flex Dynamic Skin part<div><p>To verify my assumption from the previous post, try this:</p>
<p>When you create your context with the root display object (
Application or WindowedApplication ) as a contextView, instead of
using "this", use <strong>this.parent</strong>, which is the
mx_managers_SystemManager. If the mediators for your skin parts are
created, it confirms that the components for your skin parts are
not added to the contextView's stage, but to its parent's stage,
the SystemManager stage ( top level).</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/324130742014-04-08T19:12:28Z2014-04-08T19:12:28ZMediator for flex Dynamic Skin part<div><p>Hi Ondina</p>
<p>My BugContainer is just a SkinnableContainer, I also tried using
this.parent and it comes up with :</p>
<p>warning: unable to bind to property 'parent' on class
'AppName'</p>
<p>Could you post your solution and I will take a loo at it</p>
<p>Thanks</p>
<p>Duncan</p></div>duncmcmtag:robotlegs.tenderapp.com,2009-10-18:Comment/324130742014-04-09T11:13:44Z2014-04-09T11:13:44ZMediator for flex Dynamic Skin part<div><p>Hey Duncan,</p>
<p>First of all, I have to confess that I somehow overlooked the
fact that you were using robotlegs v1, so I used robotlegs v2 for
testing your use case with the rating_demo from this article:<br>
<a href=
"http://www.adobe.com/devnet/flex/articles/dynamic_skin_parts.html">
http://www.adobe.com/devnet/flex/articles/dynamic_skin_parts.html</a></p>
<p>The RatingSkin uses a Button with (id= 'ratingButton' ) as a
dynamically added skin part. I replaced it with a custom component
RatingButton extending a Button and I mapped it to a
RatingButtonMediator. The RattingButton is added to a ratingGroup
(HGroup) which is a child of a PopUpAnchor, which in turn is added
to the SystemManager's stage. Because of that, the mediators for
the RatingButtons are not created automatically.<br>
The solutions for rl2:</p>
<ul>
<li>
<p>either use viewMannager.addContainer( ratingGroup) inside of
RatingView's mediator.</p>
</li>
<li>
<p>or mediate the RatingView and let it handle the skin parts</p>
</li>
<li>
<p>or create the context with the SystemManager as a contextView.
I'd use this only if there are no other options</p>
</li>
</ul>
<p>If the RattingButtons would be added to a container whose parent
would be the contextView, the mediators would be created
automatically and no workaround would be needed.</p>
<p>After your response, I tried the example with rl1, and, indeed,
it didn't work even when using SystemManager as a contextView. The
only solution would be to create the mediators manually inside of
RatingView's mediator, when the skin parts are added, but that's
rather cumbersome.</p>
<p>I simply didn't question the fact that you wanted to mediate the
components used as skin parts, because I thought you might have had
good reasons for doing so. But, maybe you don't need a mediator for
each skin part added, because the RatingView from my example could
dispatch custom events whenever a user interacts with the
RatingButtons, and RatingMediator could handle them. Personally, I
would opt for this solution anyway.</p>
<p>Robotlegs v2 implements a better mechanism for handling and
managing views than robotlegs v1, among other improved features. I
strongly recommend using rl2 instead of rl1, if possible :)<br>
If you decide switching to rl2 and you need help, I will go into
details about how to use the viewMannager.addContainer and so
on.</p>
<blockquote>
<p>warning: unable to bind to property 'parent' on class
'AppName'</p>
</blockquote>
<p>That's probably because you're creating the context inside fx
Declarations, where you don't have access to the SystemManger yet.
I usually initialize the context in actionscript in the
preinitialize handler of the application, and there this.parent is
the SystemManager.<br>
When using Declarations, if you want to pass the parent of the
contextView to your ApplicationContext, do this:</p>
<pre>
< fx:Declarations>
< context:ApplicationContext contextView="{SystemManager.getSWFRoot(this) as DisplayObjectContainer}"/>
< fx:Declarations>
</pre>
<p>Let me know how it goes.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/324130742014-04-17T18:14:54Z2014-04-17T18:14:54ZMediator for flex Dynamic Skin part<div><p>Hi Ondina</p>
<p>Yes I go this to work OK using RB2. Thanks I now have Mediators
initized for my dynamic skin parts.</p>
<p>Once I built up my application further I come across another few
issues I hope you can help again, and I really do appreciate your
support.</p>
<p>I have 3/4 contexts within my app. All are defined using the
ContextBuilder declaration using a Bundle which then defines a
COntextConfig. My requirements are that :</p>
<ol>
<li>
<p>I need to let the sub contexts know about the top level context
state, maybe via a Model singleton.</p>
</li>
<li>
<p>I need to dispatch top level context events which are picked up
by lower level contexts</p>
</li>
</ol>
<p>What are the best ways to do these? I have tried to define a
singleton Model on the top level COntext , and then inject this
Model into a sub context without any luck , they are always
seperate instances of the model.</p>
<p>Thanks again</p>
<p>ps I have looked at an example two contexts example at :</p>
<p><a href=
"http://knowledge.robotlegs.org/discussions/robotlegs-2/6915-best-practice-for-sharing-mappings-between-contexts">
http://knowledge.robotlegs.org/discussions/robotlegs-2/6915-best-pr...</a></p>
<p>But this example is actually using the SAME context class for
each context which is not what I want.</p></div>duncmcmtag:robotlegs.tenderapp.com,2009-10-18:Comment/324130742014-04-18T09:52:59Z2014-04-18T09:52:59ZMediator for flex Dynamic Skin part<div><blockquote>
<p>Yes I go this to work OK using RB2.</p>
</blockquote>
<p>Good decision :)</p>
<blockquote>
<p>Thanks I now have Mediators initized for my dynamic skin
parts.</p>
</blockquote>
<p>You're welcome.</p>
<blockquote>
<p>But this example is actually using the SAME context class for
each context which is not what I want.</p>
</blockquote>
<p>Hehe, Duncan, you made me think I made a mistake, so I looked at
my example again.<br>
It's not the <em>same</em> context class! There are 2 context
classes. They only look similar and have the same class name, but
one belongs to the "shell" and the other to the "module"(see
package names). You can look at the log messages in debug mode to
see how robotlegs initializes the 2 contexts. You can rename the 2
RobotlegsContext classes, if you want.</p>
<p>Or, did you mean something else?</p>
<blockquote>
<p>I have 3/4 contexts within my app. All are defined using the
ContextBuilder declaration using a Bundle which then defines a
COntextConfig.</p>
</blockquote>
<p>Each display object that is used as a contextView should
initialize its own context with its own configs.<br>
In my example, ShellMainView initializes the parent context, where
"this" is ShellMainView, and SomeView initializes a child context,
where "this" is SomeView.<br>
Did you do that? Or, did you try to initialize all 3 contexts
inside your root display object? If you did the latter, then that's
probably why you encountered some issues.</p>
<blockquote>
<p>What are the best ways to do these? I have tried to define a
singleton Model on the top level COntext , and then inject this
Model into a sub context without any luck , they are always
seperate instances of the model.</p>
</blockquote>
<p>In my example, the top level context (the shell context) is
mapping a Model as a singleton, inside of
yourdomain.shell.configs.ModelsConfig:<br>
injector.map(ISomeModel).toSingleton(SomeModel);</p>
<p>The model is then injected successfully into
yourdomain.modules.singleModule.views.mediators.SomeMediator:<br>
[Inject] public var someModel:ISomeModel;</p>
<p>That happens because the child context is inheriting the
dependencies from the parent context, when using the default
MVCSBundle, which lets the context install a ModularityExtension
with 'inherit' and 'expose' set to true by default.</p>
<p>See: <a href=
"https://github.com/robotlegs/robotlegs-framework/blob/master/src/robotlegs/bender/extensions/modularity/ModularityExtension.as#L60">
https://github.com/robotlegs/robotlegs-framework/blob/master/src/ro...</a></p>
<p><strong>inherit</strong> Should this context inherit
dependencies from a parent context?</p>
<p><strong>expose</strong> Should this context expose its
dependencies to child contexts?</p>
<p>So, if SomeModel is mapped in the parent context, the child
context will inherit the mapping and the child injector will inject
the class wherever you define an injection point. The parent and
the child contexts will share the <strong>same</strong> model (same
instance).<br>
If, on the contrary, you wanted the child context to use a
different instance of SomeModel, you'd have to map SomeModel inside
of yourdomain.modules.singleModule.configs.ModelsConfig (the config
class of the module/child context). The child injector would use
this rule instead of the parent's rule, and as a consequence, the 2
contexts will have different instances of SomeModel to work
with.</p>
<p>Just play around with my example to see how it works. There is
also a link to another example in the mentioned discussion,
ondina-robotlegs-bender-shared-configs.zip, where you can see
different ModularityExtension's settings.</p>
<blockquote>
<p>I need to dispatch top level context events which are picked up
by lower level contexts</p>
</blockquote>
<p>The ModuleConnector is what you need.<br>
Try out these examples :</p>
<p><a href=
"https://github.com/Ondina/robotlegs-bender-as3-modular-example">https://github.com/Ondina/robotlegs-bender-as3-modular-example</a></p>
<p><a href=
"https://github.com/Ondina/robotlegs-bender-modular-air">https://github.com/Ondina/robotlegs-bender-modular-air</a></p>
<p>The readme files are still a work in progress, but I think
you'll get the idea:)</p>
<p>This one is using signals instead of events:<br>
<a href=
"https://github.com/dotdotcommadot/ModularRL">https://github.com/dotdotcommadot/ModularRL</a>
, but, I suggest to get familiar with the modular connector using
events first.</p>
<p>Don't hesitate to ask questions in here, if you get stuck.
Actually, it is better to open a new discussion, under robotlegs 2,
if the problems aren't related to the dynamic skin parts anymore.
Just let me know, if the ModuleConnector examples are what you need
and whether this discussion can be marked as resolved.</p>
<p>Ondina</p></div>Ondina D.F.