Couple of small questions and clarifications.

Deril's Avatar

Deril

21 Oct, 2011 02:02 PM

Hello,

First of all - THANKS FOR GREET WORK! I work with RL for couple of weeks now and enjoin every bit of it.

I also am preparing RL workshop. I analized the code and have couple of question/clarifications:

1 : Why a lot of private variables declared as protected? (For example in Context.as checkAutoStartup, onAddedToStage, createInjector, createChildInjector, getApplicationDomainFromContextView). They just in the way in auto-completion list... and creates danger to be used instead of provided API.

2 : Is there any strong argument for context to have "eventDispatcher.addEventListener()" and "addEventListener()" functions, while Command have only "eventDispatcher. addEventListener" other than convenience? Wouldn’t it be better to stay consistent?

3 : Why command have "dispatch", and not "dispatchEvent" like Context? Consistency problem?

4 : Actor can listen to stuff?
So actor is generic model type.. and if I want to create my model protected from lets say.. Ability to register listeners I have to create my custom one? (Actualy my actor would have only public dispatch. And nothing more.)

5 : Why contextView is injected in Command by default? In most cases it will not be used. And in cases then it will be you can just inject it. Or do better. Inject ApplicationMediator and do stuff through it.

6: Why rule is returned as untyped object, instead of InjectionConfig?

7 : Command dispatch checks if there are listeners... does it actually save performance?

8: Context could hold reference to self? So it don’t get gargage collected, and released on shutdown();

Most of the questions are trivial... but I like to know the tools I am working with inside-out.

Thank you for your time!

  1. Support Staff 1 Posted by Stray on 21 Oct, 2011 11:25 PM

    Stray's Avatar

    Hi raima,

    answers as best I can give them are:

    [1] So that subclasses can overwrite those methods (for which there are good usecases)

    [2 & 3] The extra "dispatchEvent" function on the Context is there because it implements IEventDispatcher, so that outside objects can interact with the Context as an event dispatcher. All other Robotlegs classes (Mediator, Actor, Command) have "dispatch" only because they don't dispatch the event themselves, but they dispatch it on the shared eventDispatcher. Context has both.

    [4] Don't extend Actor unless you want to dispatch events. There's no need to use it other than for dispatching. It's a base class primarily intended for Services, and can be used by models that dispatch events, but only if it's convenient.

    Actor only provides the eventDispatcher injection (and an eventMap) - it's very lightweight. If you want to do something custom you're free to do that.

    [5] If a loader has loaded a swf and it now needs to be introduced to the view layer then a Command with access to contextView is a very simple way to do this. Don't inject Mediators - ever - they are not one-to-one so you have no idea which instance you will get. The ability to inject mediators has been removed from Robotlegs (it was only there as a side effect).

    [6] Not sure - Till would be able to give you the reason.

    [7] Yes. (We would not do stupid things really...)

    [8] That doesn't work. It wouldn't prevent garbage collection. Think about it...

    I hope that helps,

    Stray

  2. 2 Posted by Michal Wroblews... on 23 Oct, 2011 10:34 PM

    Michal Wroblewski's Avatar

    Hi Raima,

    [6] I think it's to prevent internal SwiftSuspenders classes from including in Robotlegs but not sure.

    Mike

  3. Support Staff 3 Posted by Till Schneidere... on 24 Oct, 2011 11:07 AM

    Till Schneidereit's Avatar

    Michal's got it almost right:
    As Robotlegs 1 allows to switch out the used DI container, it's
    impossible to rely on a return value that's specific to one DI
    container, in this case: Swiftsuspenders. The only way to work around
    that would be to get agreement on an interface to use here across all
    possible DI containers, but that would be almost impossible, as you'd
    have to in turn agree upon the interfaces used and returned by that
    types methods, etc., etc.

    With Swiftsuspenders 2 and Robotlegs 2, we have decided to get rid of
    the DI container adapters, letting Robotlegs rely directly on
    Swiftsuspenders. That way, we can use the full DSL without any
    restrictions or loose typing.

  4. 4 Posted by Deril on 25 Oct, 2011 11:03 AM

    Deril's Avatar

    Hello,

    Thanks for responses!

    [3] I get the point about IEventDispatcher. Still... for consistency maybe its better to call them all "dispatchEvent" ? Context uses eventDispatcher exactly like Mediator, Actor, Command use it ... but named differently. well it's small detail...

    [4] I am bothered with the fact that actor can listen for events. In most cases I don't want that, I just want it to dispatch. Tight coupling Model to Controller is common practice, and in most cases good idea. Because it forces your code to break then you alter Model API. Its harder to code it if you decouple it. Maybe I am missing something... or Actor is generic class for wider use, And I need custom one for dispatch only models.

    [5] I think it's good idea with mediators not being accessible in commands. In PureMVC it was possible to get mediators in commands. Still, my point was... in most cases you will not need contextView in you Command. you will use your Event to find out what to do... and Model to do it on. Your example is one shot action... and I fail to think out any other use of contextView in Command.
    Why not have... InitCommand that has contextView injected, and keep Command class free from contextView, because in almost all cases you will not use it. Or do I misunderstood something again.. :|

    [8] there are ways to make it work... but my idea is still lame. I agree.

    Thank you for your time.

  5. 5 Posted by Stray on 25 Oct, 2011 11:20 AM

    Stray's Avatar

    Hi Raima, I think the main problem here is that you are misinterpreting the purpose of the Command and Actor classes. You can easily build a Robotlegs application without these classes - the framework has no reliance on them so you can instead create your own base classes for Commands, Models and Services (or not use a base class at all).

    The Command and Actor classes were supplied to provide a quick and convenient way to get going with Robotlegs - and thus they are somewhat "one size fits all, as long as you don't need a perfect fit".

    So your comments are rather like saying "This one-size white T-Shirt that you gave away - it doesn't fit me perfectly, and it would look better with some design on it... ". The Robotlegs MVCS folder (also known as the Robotlegs trousers) is intended to provide a way to get the developer from 'naked' to 'not naked' without much effort, and so it should be judged on how it does that job, not some other purpose for which it wasn't intended!

    I've also answered in more detail below,

    Stray

  6. 6 Posted by Deril on 25 Oct, 2011 01:43 PM

    Deril's Avatar

    That's why I come to this forum! :)
    To learn interpret it in scope of framework.

    I think I found the answer to my question number [4].

    Ability to listen/dispatch events is bio-product of injected eventDispatcher. (the injection itself makes it public... and interface IEventDispatcher has to many functions..)

    It looks like I need new interface... something like: IEventDispatchOnly :)

  7. Ondina D.F. closed this discussion on 21 Nov, 2011 09:14 AM.

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