RobotLogs framework feature list.

Deril's Avatar

Deril

12 Jan, 2012 11:13 AM

Sorry for bothering you again...
I made a list of RobotLegs key features. (for workshop I am preparing...)

could you check it... and update what is missing?

THANKS!


MVC pattern based(+S added to be more fancy).

Has core class to initiate framework, and start-up. (Context)

Divides code to 3 tiers: Models(Services), Mediators, Commands.

Model(Services)

  • created by injection mapped as singleton. (class or interface)
  • created by injection mapped as predefined object.
  • created by injection mapped as new object every time on request. (there it's useful?)

  • has direct access to other Models

  • has NO direct access to Mediators

  • Can NOT listen for messages. (technically... it can.. but it should not.)

  • Can send messages.

  • Can be named. (have more then one instance of same model class under diferent name.)

Mediator:

  • can be created automatically detecting view that lands on stage. (can be disabled)
  • can be created manually.

  • has direct access to Models

  • has NO direct access to other Mediators

  • can listen for messages.

  • can send messages.

Commands:

  • executed by sent message
  • executed by other commands

  • can directly access Models

  • can NOT directly access Mediators

Communication:

  • flash event based messaging system.
  • can be extended to Signals easily. (not in main distribution)

Modular:

  • one module objects can send and receive messages from other modules.
  • modules can not directly access objects from another module.

Solves Flex object initiation difficulties.

Has option to use View only approach instead of Mediator+View approach.

  • View accessible to Commands and other Views.
  • can send and listen for messages.

Easily extendable??? (what does that stands for exactly? why its easier to extend it then some other class? )

  1. Support Staff 1 Posted by Till Schneidere... on 12 Jan, 2012 11:53 AM

    Till Schneidereit's Avatar

    Hi Deril,

    that list looks about right to me.

    The "easily extendable"-part comes from Robotlegs being based on
    automated DI. When setting up your context, you can easily add
    whatever features you want - be it Signals instead of events, view
    controllers instead of mediators or whatever you like.

    In RL2, we're trying to make that go even further by making the entire
    framework more modular. In a way, the new command map, mediator map
    and even the event dispatcher are modules, similar to those you'd
    write yourself when using the framework.

    hope that helps,
    till

  2. 2 Posted by Deril on 12 Jan, 2012 02:12 PM

    Deril's Avatar

    hm...

    is Mediators still not accessible from commands in RobotLegs 2 same as RL1?

    I failed to defend why not having this access is better to my coo-workers ..... (who mostly used to do it in PureMVC...)

  3. 3 Posted by Stray on 12 Jan, 2012 02:20 PM

    Stray's Avatar

    Short practical answer:

    1) mediators are not one-to-one, so if you have 3 instances of SomeView on the stage, and you inject an instance of SomeViewMediator, which instance should be injected? There are 3 of SomeViewMediator in existence... you might not get the right one!

    2) mediators are transitory - they are created and destroyed as the view comes and goes from the stage. So - inject an instance of SomeViewMediator, then SomeView is removed from stage, then added to stage, and now the instance of SomeViewMediator which is mediating SomeView is not the same instance that you injected.

    hth,

    Stray

  4. 4 Posted by Deril on 12 Jan, 2012 03:02 PM

    Deril's Avatar

    to Stray:

    1 : could be solved by allowing optional naming. For instance I could manually map mediator to view object and add name to find it with.

    2 : well.. don't remove the view if you intend to work with it.. :) I see the problem of automatic mediator removal... and that can happen with delay and cause problem. If view and mediator could be removed or added in same time only - that would not be a problem.

    (again... looking from PureMVC point of view - both of these is not a problem there.)

  5. Support Staff 5 Posted by Till Schneidere... on 12 Jan, 2012 03:08 PM

    Till Schneidereit's Avatar

    The difference is that in PureMVC the working hypothesis is that
    everything exists exactly once. Naming mediators makes them different
    mediators, really. And creates coupling in that somewhere you have to
    decide how to name them and have to disperse knowledge about this
    naming through the system.

    Of course, there are situations where all of that doesn't matter and
    you need to communicate directly with exactly one mediator. While I
    think that in almost all of these cases the mediator should initiate
    these communications (e.g. by dispatching an event with a callback in
    it), if you don't want to/ can't use that approach, you can always
    create a model that works as a registry for your mediators. Then you
    can inject that model into commands and thus access the mediators.

  6. 6 Posted by Deril on 13 Jan, 2012 10:05 AM

    Deril's Avatar

    To be honest... it's not the side of implementation is most interested to me. :) I understand your point about mapping in RL(and i am OK with that!). (and point about PureMVC.... it's enough to name 2 objects by mistake with same name to get why it suxz..)

    I approach is more from theoretical view of point.

    Question is... what is better - have access to mediators or not... and if limit access - why. (without thinking what RL does too much.)

    I don't have any good arguments against direct access. (only my personal style... but that does not count.)

    Also I remember the post stating that's impossible to get mediators in current RL... and it's worth consider adding in next RL releases.. (don't remember there...)

  7. 7 Posted by Stray on 13 Jan, 2012 10:39 AM

    Stray's Avatar

    Hi Deril,

    Asking why RL Mediators aren't injected into commands is like saying "This potato is defective, it totally sucks that I can't squeeze orange juice from it!" If you want orange juice (view controllers) then you really don't want to use potatoes (RL Mediators) to make it - no matter how hard you try, it'll be gross.

    Why do I say that?

    Well, the main issue is that 'Mediator' means something different in pureMVC from the meaning it has in Robotlegs.

    The way Robotlegs mediators are intended to be used - purely as a translator - there is no architecturally sound example I've yet been given for direct access to them. You would be using them as view-controllers, which they aren't suited to - if you want view-controllers then implement a view-controller layer (something that RL2 makes much easier). This view-controller layer would present APIs and would be suitable for the purpose you're talking about.

    The Robotlegs mediator has a single, well defined, purpose: to allow your view to be ignorant of application-specific events, and allow your app to be ignorant of view-specific events. (For events you can read 'messages' or 'notifications' if you're also using Signals). That's it. A different purpose would require a different solution (one that didn't involve all the mediatorMap workings that allow mediators to be automatically created and destroyed).

    A view-controller factory is actually pretty trivial to implement - you can inject it into your mediators and use them to register each view with the factory (if the factory had already registered this view then it would ignore the request). In the factory you can set up whatever you need in terms of injecting into Commands.

    I can confirm that the next RL release also doesn't automatically map mediators for injection (for all the same reasons as RL1) - though it does make it easier to add a view-controller layer or make a specific mediator available for injection with a name, in association with the automagic creation of mediators, as we've provided a way to hook into the mediator life-cycle for this purpose.

    I hope that helps you talk more with your colleagues about it - it's unfortunate that in our use of language we always end up using the same words to mean several different things.

    Stray

  8. Support Staff 8 Posted by Ondina D.F. on 13 Jan, 2012 11:27 AM

    Ondina D.F.'s Avatar

    Hey Deril,

    Well, the main issue is that 'Mediator' means something different in pureMVC from the meaning it has in Robotlegs.(Stray)

    That’s not true:)
    The roles of Mediators in pureMVC are the same as in Robotlegs. They are not meant to be View-Controllers. Also, injecting a Mediator into a Command would be considered bad practice in pureMVC too.
    So, what Stray said about Mediators in rl would be applicable to pmvc as well. Of course, it’s up to you whether you follow the recommended practice or not, be it rl or pmvc, but in many regards they are similar :)

    Ondina

  9. 9 Posted by Stray on 13 Jan, 2012 11:39 AM

    Stray's Avatar

    My bad - I thought pureMVC mediators also sometimes had methods for creating child views and so on - I'm relieved to hear that this is also an abuse of them!

    Stray

  10. Support Staff 10 Posted by Ondina D.F. on 13 Jan, 2012 01:13 PM

    Ondina D.F.'s Avatar

    Just for the sake of completeness :)

    Excerpts from pureMVC’s Best Practices ( Mediators):

    The responsibilities for the Mediator are primarily handling Events dispatched from the View Component and relevant Notifications sent from the rest of the system.
    ...

    Consider it a bad practice to retrieve other Mediators and act upon them, or to design Mediators to expose such a manipulation methods.
    ...

    The Mediator is meant to mediate communications between the View Component and the rest of the system.
    Consider the role of a translator mediating the exchange of conversation between her Ambassador and the rest of the members at a UN conference. She should rarely be doing more than simple translation and forwarding of messages, occasionally reaching for an appropriate metaphor or fact. The same is true of the Mediator’s role within PureMVC.
    ...

    A Mediator that wishes to communicate with another part of the View should send a Notification rather than retrieving another Mediator and manipulating it directly.
    Mediators should not expose methods for manipulating their stewarded View Component(s), but should instead respond only to Notifications to carry out such work.
    ...

    If much manipulation of a View Component’s internals is being done in a Mediator (in response to an Event or Notification), refactor that work into a method on the View Component, encapsulating its implementation as much as possible, yielding greater reusability.

  11. 11 Posted by Stray on 13 Jan, 2012 01:18 PM

    Stray's Avatar

    What a beautiful excerpt :)

    Thanks! I'd heard people spout about the greater flexibility of a pureMVC mediator - clearly they're bending things to their own desires there too.

    Stray

  12. 12 Posted by Deril on 13 Jan, 2012 02:09 PM

    Deril's Avatar

    Well said!

    I failed to put those arguments in a sentence... :) this helped.

    Thanks for response.

  13. Support Staff 13 Posted by Ondina D.F. on 13 Jan, 2012 03:05 PM

    Ondina D.F.'s Avatar

    What a beautiful excerpt :) Thanks! I'd heard people spout about the greater flexibility of a pureMVC mediator - clearly they're bending things to their own desires there too. (Stray)

    Yes, and they are free to do so, in my opinion. Best Practices are just recommendations, a 'Getting started guide', as you said yesterday. They cannot cover all the possible ways to use a framework. Best Practices seem to be inflexible, strict, a list of many NO-NOs, oh wait .. they really are like this, actually. But that’s exactly what they should be, in order to confer a sense of stability and safety to new comers. I see Best Practices and frameworks as bones and joints to which skeletal muscles (your own code) get anchored. They allow postural control and locomotion. How you want to move, or how flexible you become over time is a matter of experience and agility. You can become a dancer, a performer, an athlete, or a swimmer, and all these are valid, feasible, practicable or efficacious ways of moving.
    But first you have to learn how to walk, before becoming a dancer, and you have to watch and try different dance styles, tango, rave, punk, waltz, ballet, hip-hop etc to get a sense of what you like or need (the approach that best suits your project). If you want to move in a way, untypical for a particular dance style (inject mediators into commands), you are free to do so, of course, but your trainer has to make you aware of the risks of breaking your legs..
    Also, the dance steps and moves required are different from dance style to dance style (from framework to framework, but also within a framework). You can compare waltz with hip-hop if you wanted to, but it wouldn’t make much sense from a practical point of view.
    So, Deril, if you say, ‘look, that’s possible in pmvc, why is it not possible in rl’ or vice-versa, you ask the wrong questions :)

    Ondina

  14. 14 Posted by Stray on 13 Jan, 2012 03:24 PM

    Stray's Avatar

    I agree -

    There are times when it's clear that you're building something on sand. Mediators in Robotlegs are transitory, stateless (because of being transitory), have timing issues and potential reparenting issues (in RL1 at least, they can be 'paralysed' for a frame when a view is reparented). All of that can add up to memory leaks, hard-to-identify bugs and brittle code that breaks when refactored. It would be irresponsible of us not to say to people "Look, that will probably explode!", but if they really want to use it that way, they still can.

    It reminds me of when I learned to play the french horn. At the beginning you are taught to play it a certain way, because for a child this is all that is possible - you physically can't produce the force required to play it 'properly'. Then, a few years later, just when you feel like you are mastering it, your teacher says "Now we must change everything" and you have to learn a new way of playing - or you are stuck on the plateau.

    TDD is the thing that most often creates this experience for programmers as far as I can see. The day before they started using TDD, writing code felt easy. Suddenly it feels hard again... and not everybody can handle the pain while they strengthen those new muscles!

    Sx

  15. 15 Posted by Deril on 13 Jan, 2012 04:20 PM

    Deril's Avatar

    to Ondina: my question was exactly opposite: "what is best way to do it and why... despite how or what framework allows us to do.."
    It's just PureMVC and RobotLegs is the best example case for the question as they approach it differently.

    also... I really hate framework that have many NO-NO's as you put it. It defeats part of framework purpose. Good framework would not enable you to misuse it without hacking... ...and I refuse to accept any framework that does not meet this criteria.

    "hacking" should be available.. to solve special cases. but if you go that path you most likely know what you are doing and why.

  16. Support Staff 16 Posted by Ondina D.F. on 13 Jan, 2012 05:04 PM

    Ondina D.F.'s Avatar

    Yeah, but a good hacker likes it when it’s challenging. Easy code!=no fun. Kidding.

  17. Support Staff 17 Posted by Shaun Smith on 15 Jan, 2012 12:49 PM

    Shaun Smith's Avatar

    Hi Deril, the thing with a framework is that it's a subset of the features offered by a platform. A framework can never do more than what is available on a particular platform - it can only wrap up low level features into a high level API for developer convenience. The process of wrapping up low level features into a high level API places limitations on usage, and working around those limitations requires hacking.

    In the case of retrieving mediators the "hack" is one line of code added to a mediator's onRegister hook:

    function onRegister():void {
      injector.mapValue(SomeMediator, this);
    }
    

    I really hate framework that have many NO-NO's as you put it. It defeats part of framework purpose.

    It does not defeat the purpose of a having a framework at all. Frameworks are, by definition, limited. The benefit of those limitations is to reduce the possible number of ways to solve a given problem so that when working in teams, or maintaining old code, the pattern for solving that problem is immediately recognisable. Without limitations every developer on a project would solve the problem in a different way and the code would be hard to read and problematic to maintain.

  18. 18 Posted by Abel de Beer on 15 Jan, 2012 07:58 PM

    Abel de Beer's Avatar

    (haha, I love how easy that is!)

  19. Ondina D.F. closed this discussion on 23 Feb, 2012 10:34 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