tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/218-fb-and-modular-rl-compatibilityRobotlegs: Discussion 2018-10-18T16:35:20Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-17T22:00:05Z2010-11-17T22:00:05ZFB and Modular RL compatibility?<div><p>Hi Tyler, this is a bit weird because, afaik, there is nothing in robotlegs that is flex-dependent at all - it's an actionscript framework which works for flash, flex or as3.</p>
<p>I'll clone joel's fork and check if I can find anything that would be relevant.</p>
<p>Which RL build are you using?</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-17T22:03:31Z2010-11-17T22:03:33ZFB and Modular RL compatibility?<div><p>I'm using everything from Joel's fork. the major change from Halo to Spark where it pertains to RL would likely be addElement over addChild. I'm completely baffled as to how creating a mediator with an injected Interface mapped view to this would cause it to fail like it is. No mediator, everything works fine.</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-17T22:08:59Z2010-11-17T22:08:59ZFB and Modular RL compatibility?<div><p>When it comes to adobe, nothing ever surprises me ;)</p>
<p>there's definitely nothing relevant in the modular source.</p>
<p>What I'd recommend is that you build from the modular source, but with the RL 1.4 source or swc, as it might be something accidentally included in the RL 1.1 swc</p>
<p>Jeremy had a very similar problem earlier today - it presented differently by the halo/spark border skin issue is also what he was seeing. Building against the RL 1.4 framework seems to have fixed it. His thread is here: <a href="http://knowledge.robotlegs.org/discussions/problems/217-robot-legsflashbuilder-4">http://knowledge.robotlegs.org/discussions/problems/217-robot-legsf...</a></p>
<p>I'm afraid I'm a flex-dummy - I only use AS3 really. Hopefully if that doesn't fix it then the flexperts will be along shortly.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-17T22:18:31Z2010-11-17T22:18:32ZFB and Modular RL compatibility?<div><p>Ok, I'll give it a shot, wasn't sure if Modular was compatible with RL 1.4. Is there any plan to have modular shadow RL releases?</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-17T22:52:14Z2010-11-17T22:52:15ZFB and Modular RL compatibility?<div><p>Hmm, Unfortunately RL 1.4 didn't resolve my problem. Is there a way to add a mediator without the need for class mapping? By passing in the instance and the mediator requested?</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-17T23:15:47Z2010-11-17T23:15:47ZFB and Modular RL compatibility?<div><p>Hello,</p>
<p>What's the actual error message?</p>
<blockquote><p>Is there any plan to have modular shadow RL releases?</p></blockquote>
<p>It doesn't need to as Robotlegs adheres to Semantic Versioning: <a href="http://semver.org/">http://semver.org/</a></p>
<blockquote><p>I'm completely baffled as to how creating a mediator with an injected Interface mapped view to this would cause it to fail like it is.</p></blockquote>
<p>What does the mapping look like?</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-17T23:20:46Z2010-11-17T23:20:46ZFB and Modular RL compatibility?<div><p>It turns out it was an incompatibility with another component contained in the module. Fixing that makes it work, but it's odd that having the mapping would expose this problem while not having it means everything runs smoothly.</p>
<p>Looking forward to being able to map interfaces though, great work everyone!</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-18T08:24:54Z2010-11-18T08:24:54ZFB and Modular RL compatibility?<div><p>Brilliant - and it might have been just that the mapping exposed it early, if it was an RTE waiting to happen?</p>
<p>As Shaun said - the versions are inter-compatible (almost always) - the reason I suggested pulling down the 1.4 swc was just incase something unnecessary had got compiled into the swc on Joel's modular fork accidentally.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-18T13:36:24Z2010-11-18T13:36:25ZFB and Modular RL compatibility?<div><p>I've successfully loaded this same module multiple times in many different formats. RL must do something to the creation and instantiation phase that exposed the problem. We were hoping to avoid having to upgrade the 3rd party component to Spark, but it looks like it's for the best.</p>
<p>Thank you both for your assistance.</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-18T15:25:58Z2010-11-18T15:26:00ZFB and Modular RL compatibility?<div><p>This issue seems to be rearing it's ugly head again... I'm wondering, would RL's mapping have a problem with modules loaded via IModuleInfo and instantiated using a factory instance?</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-18T17:08:36Z2010-11-18T17:08:36ZFB and Modular RL compatibility?<div><p>Hi Tyler,</p>
<p>I have no idea, but this is worth sorting out. Can you create a minimal-implementation that recreates it?</p>
<p>Then some of the flexers that are also across modular - for example Joel - should be able to get to the bottom of it.</p>
<p>The ideal would be to upload a project to github that we can dig into.</p>
<p>Is that viable?</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-18T18:21:17Z2010-11-18T18:21:17ZFB and Modular RL compatibility?<div><p>Unfortunately, no, I am not allowed to post the source. Recreating a minimalist version may not show the issue at all, as I've discovered a few more things...</p>
<ol>
<li>The module in question, when added to the stage beforehand instead of being loaded, will accept the mapping.<br />
</li>
<li>The module can be loaded externally without mapping and it runs fine.<br />
</li>
<li>The module can be loaded either by IModuleInfo or ModuleLoader and the mapping causes the error.<br />
</li>
<li>Other modules accept both external loading and mapping, so it's something specific to this module.</li>
</ol>
<p>I'm doing more research on it and I'll let you know if I find a solution. I think part of the problem could be due to the hybrid nature of the components, as I'm using Spark components inside a Halo Module, because Adobe unfortunately didn't feel like it needed to upgrade ALL of it's Halo components :).</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-18T22:28:27Z2010-11-18T22:28:27ZFB and Modular RL compatibility?<div><p>That sounds</p>
<ol>
<li>Crazy<br />
</li>
<li>Frustrating<br />
</li>
<li>Like you may eventually have to put it down to an undocumented weirdness on the Spark / Halo combo front.</li>
</ol>
<p>I hope you find a solution - good work narrowing it down - it'll be useful for others hitting the same issue.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-19T13:56:08Z2010-11-19T13:56:10ZFB and Modular RL compatibility?<div><p>At the moment the major errors seem to be in the layout process during the creation phase. does RL have any influence over this area? I'm getting errors where widths / heights aren't being set.</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-19T16:31:46Z2010-11-19T16:31:48ZFB and Modular RL compatibility?<div><p>Well, I've officially ruled out RL as the problem. I can recreate it without any RL at all. Apparently loading a module that's been built to depend on the app you're loading it into means you can't have a direct reference to the incoming module class. RL's viewMap does this.</p>
<p>However, even in a simple test of loading the module independently, with no reference to the module class within the parent application, the module fails to load at all. I can't win.</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-19T17:00:41Z2010-11-19T17:00:44ZFB and Modular RL compatibility?<div><p>It appears that Flex 4's style implementations mean that you cannot have a direct reference to the class within the application that loads the module if you've built your module with dependencies. The recommendation is to use interfaces to communicate. However, RL doesn't support interface mediator mapping, so I suppose I'll have to create mediators manually?</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-19T17:19:42Z2010-11-19T17:19:42ZFB and Modular RL compatibility?<div><p>Interface for the view?</p>
<p>2 options:</p>
<p>1) If you know the interface, just do</p>
<pre><code>mediatorMap.mapView(SomeModule, SomeModuleMediator, ISomeModule) // 3rd param is 'injectViewAs'</code></pre>
<p>2) There's a RL alternative mediator map that allows interfaces, as created by piercer:</p>
<p><a href="https://github.com/piercer/robotlegs-extensions-ViewInterfaceMediatorMap">https://github.com/piercer/robotlegs-extensions-ViewInterfaceMediat...</a></p>
<p>Hopefully one of those will sort you out!</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-19T17:28:51Z2010-11-19T17:28:52ZFB and Modular RL compatibility?<div><p>Yeah, I've been using the injectAs, problem is... as soon as you have the reference to the concrete class, as in "SomeModule", it breaks the style inheritance in Spark.</p>
<p>I'll try <a href="/discussions/problems/2" title="Discussion #2">#2</a> and see how it goes, though my one concern would be what if a loaded module implements multiple interfaces? I think I'm going to have to get specific in my casting to mediators, perhaps through a factory. All of my mediators require the interface injection regardless so while I'd rather just do the view mapping beforehand, I will do it manually upon loading if I have to. Would make it possible to assign multiple mediators to the same module should that module implement multiple interfaces.</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-19T17:33:36Z2010-11-19T17:33:36ZFB and Modular RL compatibility?<div><p>You can also do multiple extensions in a marker interface - eg:</p>
<pre><code>public interface BlueSquareDraggableInterface extends BlueInterface, SquareInterface, DraggableInterface</code></pre>
<p>Which might, or might not, be useful.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-19T18:50:37Z2010-11-19T18:50:38ZFB and Modular RL compatibility?<div><p>Yes, I have interfaces that extend other interfaces, but my question is, if my module supported multiple interfaces, which mediator would get injected if I had multiple mappings?</p>
<p>I think for my purposes it may be better to do this manually. Can I pass an instance of an interface, and the interface to a method to create the mediator for it?</p></div>Tyler Padleytag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-19T23:02:47Z2010-11-19T23:02:47ZFB and Modular RL compatibility?<div><blockquote><p>However, RL doesn't support interface mediator mapping [..]</p></blockquote>
<p>It does, but you have to pass the Fully Qualified Class Name through as a String (for performance reasons):</p>
<pre>
mediatorMap.mapView( 'org.project.module::SomeView', SomeMediator, ISomeView );
</pre>
<p>When using <code>injectAs</code> it's pretty common to pass the FQCN string as the first param so as to avoid compiling module code into the shell application. The interface is compiled into both the module and the shell, but is always tiny (so long as it doesn't "leak").</p>
<p><a href="https://github.com/robotlegs/robotlegs-framework/blob/v1.4.0/src/org/robotlegs/core/IMediatorMap.as#L21">https://github.com/robotlegs/robotlegs-framework/blob/v1.4.0/src/or...</a></p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/38544872010-11-22T13:46:22Z2010-11-22T13:46:24ZFB and Modular RL compatibility?<div><p>Shaun, I was referring to being able to map an interface to a mediator. Stray's suggestion of the piercer extension is what I'm looking for.</p></div>Tyler Padley