FB and Modular RL compatibility?
I have been working with Modular RL Joel Hooks branch 1.1 I believe, and I'm trying to figure something out... I'm loading a flex Module and adding it to the Shell's stage.... this works perfectly fine... however, if I include a mediator mapping of that Module's class, it suddenly breaks, giving me a type conversion error as it fails to convert the halo border skin to the new spark border skin. The Module, while an MX component, is completely built with spark components and loads into the app just fine without the mediator mapping.
Is there something in the ModuleMediator that tries to retrofit the class to halo components? Is there a RL, in particular a Modular RL that is specifically designed for FB 4 and the Spark component set?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Stray on 17 Nov, 2010 10:00 PM
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.
I'll clone joel's fork and check if I can find anything that would be relevant.
Which RL build are you using?
2 Posted by Tyler Padley on 17 Nov, 2010 10:03 PM
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.
3 Posted by Stray on 17 Nov, 2010 10:08 PM
When it comes to adobe, nothing ever surprises me ;)
there's definitely nothing relevant in the modular source.
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
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: http://knowledge.robotlegs.org/discussions/problems/217-robot-legsflashbuilder-4
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.
Stray
4 Posted by Tyler Padley on 17 Nov, 2010 10:18 PM
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?
5 Posted by Tyler Padley on 17 Nov, 2010 10:52 PM
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?
Support Staff 6 Posted by Shaun Smith on 17 Nov, 2010 11:15 PM
Hello,
What's the actual error message?
It doesn't need to as Robotlegs adheres to Semantic Versioning: http://semver.org/
What does the mapping look like?
7 Posted by Tyler Padley on 17 Nov, 2010 11:20 PM
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.
Looking forward to being able to map interfaces though, great work everyone!
8 Posted by Stray on 18 Nov, 2010 08:24 AM
Brilliant - and it might have been just that the mapping exposed it early, if it was an RTE waiting to happen?
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.
9 Posted by Tyler Padley on 18 Nov, 2010 01:36 PM
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.
Thank you both for your assistance.
10 Posted by Tyler Padley on 18 Nov, 2010 03:25 PM
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?
11 Posted by Stray on 18 Nov, 2010 05:08 PM
Hi Tyler,
I have no idea, but this is worth sorting out. Can you create a minimal-implementation that recreates it?
Then some of the flexers that are also across modular - for example Joel - should be able to get to the bottom of it.
The ideal would be to upload a project to github that we can dig into.
Is that viable?
12 Posted by Tyler Padley on 18 Nov, 2010 06:21 PM
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...
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 :).
13 Posted by Stray on 18 Nov, 2010 10:28 PM
That sounds
1. Crazy
2. Frustrating
3. Like you may eventually have to put it down to an undocumented weirdness on the Spark / Halo combo front.
I hope you find a solution - good work narrowing it down - it'll be useful for others hitting the same issue.
14 Posted by Tyler Padley on 19 Nov, 2010 01:56 PM
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.
15 Posted by Tyler Padley on 19 Nov, 2010 04:31 PM
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.
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.
16 Posted by Tyler Padley on 19 Nov, 2010 05:00 PM
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?
17 Posted by Stray on 19 Nov, 2010 05:19 PM
Interface for the view?
2 options:
1) If you know the interface, just do
mediatorMap.mapView(SomeModule, SomeModuleMediator, ISomeModule) // 3rd param is 'injectViewAs'
2) There's a RL alternative mediator map that allows interfaces, as created by piercer:
https://github.com/piercer/robotlegs-extensions-ViewInterfaceMediatorMap
Hopefully one of those will sort you out!
18 Posted by Tyler Padley on 19 Nov, 2010 05:28 PM
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.
I'll try #2 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.
19 Posted by Stray on 19 Nov, 2010 05:33 PM
You can also do multiple extensions in a marker interface - eg:
public interface BlueSquareDraggableInterface extends BlueInterface, SquareInterface, DraggableInterface
Which might, or might not, be useful.
20 Posted by Tyler Padley on 19 Nov, 2010 06:50 PM
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?
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?
Support Staff 21 Posted by Shaun Smith on 19 Nov, 2010 11:02 PM
It does, but you have to pass the Fully Qualified Class Name through as a String (for performance reasons):
When using
injectAsit'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").https://github.com/robotlegs/robotlegs-framework/blob/v1.4.0/src/or...
22 Posted by Tyler Padley on 22 Nov, 2010 01:46 PM
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.
Stray closed this discussion on 11 Feb, 2011 05:23 PM.