Some pure-as3 modularity extension example for RL2

greenLED's Avatar

greenLED

29 Mar, 2014 09:23 PM

Hi. I am getting my hands in RL2 and loving it more and more. Great job!!

I am trying to implement a trivial use case where I have a shell which loads a module and shares with it a previously mapped model. I am writting a pure-as3-air app, both shell and module, and they are in separated projects. The problem is that I have no idea about how to connect the shell and the module. I am using a Loader with the module. Do you have some working example of non Flex modular app for RL2? Thanks in advance.

  1. Support Staff 1 Posted by Ondina D.F. on 30 Mar, 2014 05:43 PM

    Ondina D.F.'s Avatar

    Hello,

    I've attached a very simple example of a pure as3 modular app.
    I've put it together very quickly, so it's not perfect ;)
    It is an AIR app. I've used FlashBuilder 4.6 to specify the action script module used in this example (ModuleAView).
    The ModuleLoaderView loads ModuleAView.
    It's getting late here, where I live, so I'm going to tell you more about how it works tomorrow, if need be.

    The attached as3 app is similar to this one for Flex:
    https://github.com/Ondina/robotlegs-bender-modular-air

    And here is another example (Flex) using signals:
    https://github.com/dotdotcommadot/ModularRL

    Ondina

  2. 2 Posted by greenLED on 01 Apr, 2014 03:58 PM

    greenLED's Avatar

    Hello Ondina. Thanks a lot for your example. I made my code work, can't believe it was so simple :) Reading your code raises two questions on me:

    Is there any special reason to wait for Event.ADDED_TO_STAGE before loading the module in ModulesLoaderView and before adding context and clindren in ModuleAView? Is it some kind of good practice?

    You are mediating your module context view. Isn't it a discouraged practice? Where is the limit when mediating root views without getting in troubles?

  3. Support Staff 3 Posted by Ondina D.F. on 02 Apr, 2014 11:26 AM

    Ondina D.F.'s Avatar

    Hi,

    You're welcome. :)
    I'm glad my example was helpful.
    In the meantime I've changed it a bit. Even though it is still WIP, I've uploaded it on github:
    https://github.com/Ondina/robotlegs-bender-as3-modular-example

    The readme is a work in progress as well. It's easier to write code than a good readme, and also less time consuming ;)

    The example uses a shared library for some components, models and events, and it is also capable of loading another robotlegs app as a swf. There are 2 other repositories there for the library and external app. I'll explain the work flow in the readme as soon as I get a chance.

    Is there any special reason to wait for Event.ADDED_TO_STAGE before loading the module in ModulesLoaderView and before adding context and clindren in ModuleAView? Is it some kind of good practice?

    I guess the only reason for using addedtostage was that the stage was null in the constructor of the module and I wanted to scale the stage or something, but forgot to do so, in the hurry..
    I'll make sure to change this in the github example. If you find any other issues, please let me know.

    In fact, it is better to create the context of a pure actionscript project in the constructor of a child view of the document view. The reason for that is StageSyncExtension's way of handling the contextView of a non-Flex application. For more details see this discussion:
    http://knowledge.robotlegs.org/discussions/robotlegs-2/3724-ieventd...

    You are mediating your module context view. Isn't it a discouraged practice? Where is the limit when mediating root views without getting in troubles?

    There are many situations where a Mediator for the contextView is needed, and there are lots of questions on this forum asking how to do it. So I'd made it a habit to create a mediator for a contextView whenever I write an example, just to show how it's done.

    Isn't it a discouraged practice?

    Can you point me out to the article(s) or discussion(s) that made that statement? Maybe they were referring to robotlegs version 1?
    And, what kind of troubles are you expecting to get into?

    Ondina

  4. 4 Posted by greenLED on 02 Apr, 2014 11:42 PM

    greenLED's Avatar

    > Can you point me out to the article(s) or discussion(s) that made that
    > statement? Maybe they were referring to robotlegs version 1? And, what
    > kind of troubles are you expecting to get into?

    You are right. Some days ago I read an article from the Knowledge Base
    named "Can I Mediate my Root Application?" and in fact, as I can see in
    the sintax it shows, it refers to RL1. As the article says, I could end up
    with an uninitialized context, but again, it is for RL1. Does it means
    there is no null context risk in RL2 whem mediating the root application?

    I saw your updated example at GitHub. The readme.md explains a lot the
    inter modular comunication process. Thanks again :)

  5. Support Staff 5 Posted by Ondina D.F. on 03 Apr, 2014 10:39 AM

    Ondina D.F.'s Avatar

    As the article says, I could end up with an uninitialized context, but again, it is for RL1.

    You misunderstood the article. The context would be initialized just fine. Having a mediator for the root display object that is used as a contextView doesn't affect context's initialization. It is rather the other way around. Classes, like Mediators, Models, Commands, Services, will be fully functional only after a context has been created and the wiring process has finished (mappings..). If such a framework class is created before the robotlegs start up process has finished, it won't be supplied with the needed dependencies.

    Robotlegs v2 handles the initialization process much better than rl1. The context's lifecycle handlers come in pretty handy. For example, afterInitializing() means that the context has been fully initialized and your classes have been configured. The application is ready - up and running.
    You can follow the flow of a context initialization process by looking at the log messages in debug mode.

    Does it means there is no null context risk in RL2 whem mediating the root application?

    The null context problem has also nothing to do with mediating the root display object.
    See this:
    https://github.com/robotlegs/robotlegs-framework/wiki/Common-Proble...

    The only problem with a mediated root view could be what is called "a race condition". For example, if the mediator added a listener for an event dispatched by the view, and the event has been dispatched before mediator's initialize(), the mediator won't be able to react to the event. But, such a situation can be easily circumvented.
    With dependency injection, race conditions can arise in other parts of your application as well. But, you can avoid them, if you carefully design your classes. Keep in mind that the order of execution / the timing of events or processes are important and that dependencies must be satisfied before using them.
    There are also some utilities, that can be of help when dealing with the order of the execution of events or commands, but that's another story:)

    Do you need more assistance with the modular extension or can we mark this discussion as resolved?

  6. 6 Posted by greenLED on 03 Apr, 2014 01:09 PM

    greenLED's Avatar

    Yes, you can mark this discussion as solved. I am fine with modules for
    now. Thanks Ondina, and sorry for the offtopics.

  7. Support Staff 7 Posted by Ondina D.F. on 03 Apr, 2014 02:15 PM

    Ondina D.F.'s Avatar

    My pleasure! Don't worry about the offtopics. It's better to clear up doubts right away than to live with them :)

    See you around,
    Ondina

  8. Ondina D.F. closed this discussion on 03 Apr, 2014 02:15 PM.

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