If you are a fan of Robotlegs (I am), check out Omar's port of Robotlegs for use w/ the Starling Framework. Huge thanks to Omar (s9tpepper)!
Blog post: http://labs.almerblank.com/2011/10/robotlegs-support-for-starling-framework/
GitHub: https://github.com/s9tpepper/robotlegs-starling-plugin
Very nice John, thanks for sharing the links here.
Thibault
Wow, that's great news! Thanks for sharing, John -- and thanks to Omar, if you read this! =)
Hi, I just wanted to try out the robotlegs-starling port example, but ran into some issues. The Mediator for the context view was created, but all Mediators of the child views are not created.
Has anyone got the example to work already?
I just did some debugging and looked into the source code and found out that the StarlingMediatorMap is relying on the fact, that the Event.ADDED, Event.REMOVED, Event.ADDED_TO_STAGE, Event.REMOVED_FROM_STAGE is bubbling up to the context view. Is this working like that in Starling? At least in my case it's not behaving that way.
[EDIT]I just looked through the Starling code and found that in DisplayObjectContainer in the addChildAt method the Event.ADDED, and Event.ADDED_TO_STAGE are dispatched with bubble=false. Is there a specific reason why these events shouldn't bubble up in Starling?[/EDIT]
[EDIT AGAIN]Actually the only way to get the robotlegs framework running with the current Starling framework would be to extend all views that need Mediators with listeners for all required events(Event.ADDED, Event.REMOVED, Event.ADDED_TO_STAGE, Event.REMOVED_FROM_STAGE) and then re-dispatch them with bubbbles=true.
...
if (!event.bubbles) {
event.stopImmediatePropagation();
dispatchEvent(new Event(event.type, true));
}
...
I'd love not to implement such kind of workaround...
[/EDIT AGAIN]
Christoph
Robotlegs doesn't rely on bubble anyways does it? It grabs the events during the capture phase I thought... a port should work the same way probably.
Kudo for this library! I used RobotLegs in all my projects, and it really hels keep everything neat, tidy, and flexible.
I've to admit that I haven't used robotlegs so far in any Display List projects. I just had a look at the robotlegs source code. As far as I can see it also relies on the fact that it captures the events(Event.ADDED_TO_STAGE and Event.REMOVED_FROM_STAGE) in the context view. In Starling there is no such thing as a capture phase, right now. So the only solution would be a workaround like the one I mentioned in my previous comment.
I did a quick patch of the Starling framework changing the Event bubbling and now also the robotlegs library works 
Thanks for posting that ripcurlx. While I was doing the port I realized that Starling did not implement capture phase in events and I had to switch the events being dispatched to bubbling. I forgot to submit the Starling changes as a patch request and make note of it in the library documentation.
I'm going to do an update tonight to the docs on the site and see if there's any other way I can get this to work without changing Starling, or submit a Starling patch request if there is no other option.
I also have to run some tests on Command objects as I have had a couple of reports from people saying the Command mapping is failing.
I see that the project in Github has no recent updates, is this plugin working ok right now?, did anyone try it in a full implementation?
Thanks Omar for all your work on this, appreciated.
Hi I'm using starling framework for first time. I have worked on robotlegs in past, I am working on some app, So I thought to use starling + robotlegs. Many things are works fine and can be achievable, I am facing one issue.
- How we dispatch event from mediator class (i.e framework event). So that every other mediator or wherever we required that event we can listen.
Thanks in advance, Any help is really appreciated!
I'm not using Omar's port since I didn't want to have to make my RL specifically "Starling-flavored", so I simply wrote a StarlingMediatorMap like this:
package net.sfmultimedia.starling { import org.robotlegs.core.IInjector; import org.robotlegs.core.IMediator; import org.robotlegs.core.IReflector; import org.robotlegs.mvcs.Actor; import flash.utils.Dictionary; import flash.utils.getDefinitionByName; import flash.utils.getQualifiedClassName; /** * This shim allows Starling views to have mediators just like Regular Native views * * @author mtanenbaum */ public class StarlingMediatorMap extends Actor { private var injector:IInjector; private var reflector:IReflector; private var mediatorMap:Dictionary = new Dictionary(true); private var mediatorByView:Dictionary = new Dictionary(true); public function StarlingMediatorMap(injector:IInjector, reflector:IReflector) { super(); this.injector = injector; this.reflector = reflector; } public function mapView(viewClass:Class, mediatorClass:Class):void { var fqcn:String = getQualifiedClassName(viewClass); mediatorMap[fqcn] = mediatorClass; injector.mapClass(mediatorClass, mediatorClass); } public function createMediator(viewComponent:Object):IMediator { if (viewComponent == null) { throw new Error("StarlingMediatorMap :: createMediator...View is null"); } var fqcn:String = getQualifiedClassName(viewComponent); var classObject:Class = getDefinitionByName(fqcn) as Class; var mediatorClass:Class = mediatorMap[fqcn]; if (mediatorClass == null) { throw new Error("StarlingMediatorMap :: createMediator...mediatorClass is null. did you remember to map it in the context?"); } injector.mapValue(classObject, viewComponent); var mediator:IMediator = injector.instantiate(mediatorClass); mediatorByView[viewComponent] = mediator; injector.unmap(classObject); return mediator; } public function removeMediator(mediator:IMediator):IMediator { if (mediator) { var viewComponent:Object = mediator.getViewComponent(); delete mediatorByView[viewComponent]; mediator.preRemove(); mediator.setViewComponent(null); injector.unmap(reflector.getClass(mediator)); } return mediator; } /** * @inheritDoc */ public function removeMediatorByView(viewComponent:Object):IMediator { return removeMediator(retrieveMediator(viewComponent)); } /** * @inheritDoc */ public function retrieveMediator(viewComponent:Object):IMediator { return mediatorByView[viewComponent]; } } }
Inject this in your context and then use it like this:
var starlingMediatorMap:StarlingMediatorMap = injector.getInstance(StarlingMediatorMap); starlingMediatorMap.mapView(SomeView, SomeViewMediator);
This puts your mediators into the RL instance and on the main communication bus.
There is one important caveat: my system does not automatically create/destroy mediators, so somewhere you need a command to do that for you (this is where Omar's port is better -- or at least more automatic -- than my solution). I have a NavigationCommand that handles this like so:
child = viewModel.getById(id); mediator = starlingMediatorMap.createMediator(child); someView.addChild(child); mediator.onRegister();
HTH
Normally i am using AS3 Navigator for handling robot legs views, anyone got any success using it with starling?
Would it be reasonable to add all displayobjects directly to contextView from mediated view components instead of just adding them to the mediated view components?
Could it have any effect on the performance?
The displayList would be "thinner", however there would still be the empty mediated view components..
You must log in to post.
