Some tricks when switching to Robotlegs from PureMVC

From the past posts and a couple of tweets, you all know I have been playing around with Robotlegs. Also, up until now, my framework of choice has been PureMVC, so what I want to do in this post is inform you of the little road bumps I hit when trying to learn the new framework.

Public dependency injection

The first one is really small. Robotlegs makes use of dependency injection (more on that in a later post) and to do so you have to put a meta tag [Inject] before you variable declaration. That is all good, just remember to make your variable public or else you’ll get an error. I wasn’t accustomed with the error I got so it took me some time to find out why I got it.

[Inject]
public var view:Footer; //remember to make public injectable variables

Playing with models

First thing first, when creating my model I was looking to extend the Model class from the Robotlegs framework. Turns out there is no such class; models should extend the Actor class. Services also extends the Actor class.

The next gotcha was a little weird to me at first because it is different from PureMVC mindset. Robotlegs does lazy instantiation, so when you map a model using the injector.mapSingleton method the model will only be created the first time it is injected (that is how I understood it). For some models this is ok, but for others they need to be created before that. In order to do so you use injector.instantiate method and pass it the class you want to create. Here is the code for it and how you would pass data to your newly created model:

injector.mapSingleton(ApplicationModel);
var appModel:ApplicationModel = injector.instantiate(ApplicationModel);
appModel.init("whatever you want here");

Where do I list and handle framework events?

This is the big plus for Robotlegs, no more handling notifications but not listing them and then not figuring out why it doesn’t work. Robotlegs uses the same┬ámechanism, in a mediator, to listen to view events than to listen to framework events which makes it easier to deal with.

So to listen to a view event I would do this:

eventMap.mapListener(view, StringEvent.HIT_ZONE_ROLL_OUT, _onRollOut, StringEvent);

and to listen to a framework event I would do this:

eventMap.mapListener(eventDispatcher, StringEvent.RESIZE, _onResize, Event);

Robotlegs basically wraps around the traditional addEventListener method and what does this give us as an additional bonus? We don’t ever have to set these listeners to weak reference because that is the way they are set by default. Oh, the joy!

Learning a new framework isn’t an easy task (at least when you don’t know any), but I found that learning Robotlegs from a PureMVC background was pretty easy. I hope you will take the time to check it out.

, , ,

  1. #1 by Joel Caballero - February 25th, 2010 at 17:47

    Going through the same thing right now. Thanks for shedding some light on it.

  2. #2 by Joni - February 27th, 2010 at 22:31

    Same here.
    I have a question that maybe you (or anyone else) can answer:

    I want to inject a property from a Model in a viewComponent (not a mediator).

    Say you have a ImageGalleryModel, which has a property called showTime. It returns a Number indicating the amount of seconds the image should show.

    So then I have an Image viewComponent and I want to Inject the showTime property from the ImageGalleryModel.

    How could I do that? Any ideas?

  3. #3 by zedia.net - March 1st, 2010 at 18:08

    If you what you want to do is to directly inject some Model data into your view without passing by the mediator, I would strongly advise against it. The logic behind PureMVC and I guess it is the same in Robotlegs is to keep the views framework agnostic, meaning they don’t know anything about the framework they are in and could work in any. It is the mediator’s job to do the communication between the framework and the view, so in this case you would inject the model in the mediator and the model would pass the data using a public method of the view. If you still want to do what you first wanted, I am not yet good enough with Robotlegs to answer that; you could ask on the Robotlegs forum. They would probably have an answer for you.

  4. #4 by Joni - March 3rd, 2010 at 14:55

    Yes, that makes sense.

    But I still see the same problem and can’t figure it out yet.

    Even if I inject the model into the mediator, I’m injecting the entire model itself.

    Is it possible to inject just one property?
    I would say you have to use the mapValue function, but what happends if the value to be mapped (and then injected) is of type Number, or String?

    I’ve tried naming the injection but couldn’t make it to work.

    Well, any ideas are of great help! Thanks!

  5. #5 by kyoji - March 14th, 2010 at 10:59

    injector.mapSingleton(AppModel);
    var appModel:AppModel = injector.instantiate(AppModel);
    appModel.init(“hello”);

    These dosen’t work for me. I change that a bit:

    var appModel:AppModel = new AppModel();
    appModel.init(“hello”);
    injector.mapValue(AppModel, appModel);

    Bug? I am using v1.0.3

  6. #6 by shaun - August 1st, 2010 at 07:11

    Hi, your advice regarding forced instantiation of instances is incorrect. I realize that it’s a bit confusing, but “instantiate” does not do what you are expecting. What you are looking for is “getInstance”. The difference is quite subtle, but very important:

    “instantiate” will always create a new instance of a class. It won’t obey the mapping rules (like mapSingleton etc), it will simply construct a new instance of whatever class you pass it. It is used by things like the MediatorMap and CommandMap to construct new Mediators and Commands. It is a handy way to construct an instance and have it’s dependencies satisfied without needing to set up any rules.

    “getInstance” will retrieve (or create) an instance based on previously mapped rules. If a rule has not been set up an error will be thrown. If you have mapped something as a singleton getInstance will always return the same instance for that class/interface. Essentially, getInstance is what you’d normally use.

  7. #7 by zedia.net - August 1st, 2010 at 17:52

    @ shaun
    Thank you for this, I had found out it wasn’t working but didn’t know why. I was using a workaround to do the same but it felt way dirty. Now I can do it the right way. Thank you .

(will not be published)
Subscribe to comments feed