Presentation model vs. mediator design pattern

elad.ny's Avatar

elad.ny

11 Dec, 2009 01:37 AM

RobotLegs is using the mediator design pattern, which includes the logic and computation as well as defines the interface for communication between objects. In RobotLegs it would be nice if I can somehow set the view to be completely passive so it will only include the view and what’s related to the view. The view will than include:

  1. State
  2. Transitions
  3. Components and sub-components

What I would prefer to do is set the mediator to include all the logic and data so I can leave the view “clean” of logic and data. For instance, let’s say I want to implement the preinitialize I would implement that logic in the mediator and not in the view. However, with the current architecture I cannot achieve this type of architecture and in fact in examples such as imagegallery (see GalleryView.mxml http://examples.robotlegs.org/imagegallery/srcview/index.html ), the view includes both logic and view (UIComponents). The mediator right now expose the creation complete but fail to expose every part of the component's init process

I am thinking out loud here.. but maybe the approach is to implement some sort of passive presentation model so I can create a better MVC separation.

Why would I want to do that? Using a presentation model will allows me to easy unit test my application better, since I can create test cases just for the logic and if needed test cases for the view. Additionally, I can replace my view easily and create different views for the same logic, which will help big time with Flex 4 new architecture and Flash Catalyst.

So using presentation model such as passive view I can than split my laundry to two piles, view and presenter:

View:
1. State is in the view
2. Transitions
3. View is passive and is not aware of the Presenter

Presenter:
1. Logic is in the Presenter.
2. Presenter observes view events
3. Presenter updates the view data.
4. Presenter ‘knows’ about the components in the view.
5. Presenter holds the data or point to a data class.

Any thoughts?

  1. Support Staff 1 Posted by Shaun Smith on 11 Dec, 2009 02:12 PM

    Shaun Smith's Avatar

    Hi Elad,

    Leaving aside discussions of Mediator vs Presenter for a moment, a quick note about the RL Mediator implementation and its life-cycle:

    There is a preRegister hook that you can override in your concrete mediators. This will give you access to the view component the moment that RL gets hold of it (but after injection has taken place). The MediatorMap calls mediator.preRegister after injection, and it is actually the Mediator that calls it's own onRegister hook when it feels it is ready to be used (in the case of a Flex mediator, after creation complete).

    Next up - The ViewMap:

    You could use the ViewMap to inject into view components directly. This would allow for an easier implementation of the Presenter pattern. Your view component would then need to have a property marked for injection on it. That property would be the presenter. Something like this (on the view component):

    [Inject]
    public var presenter:MyComponentPresenter;
    

    To pass a reference of the view through to the presenter, you'd need something like this (also on the view comp):

    [PostConstruct]
    public function initPresenter():void
    {
      presenter.setView(this);
    }
    

    Alternatively, a slightly naughty way to combine both of the above would be:

    [Inject]
    public function initPresenter(presenter:MyComponentPresenter):void
    {
      presenter.setView(this);
    }
    

    Regardless, both of the approaches require editing your view components directly - which is something that the Mediator avoids.

    On the other hand, they are simpler to implement that the Mediator pattern - as the view component itself has a reference to the presenter instance we can leave GC up to the view component: when it leaves the stage (assuming there are no other refs to it) the presenter will die along with the view. With a Mediator this is more complex as the view component doesn't have a ref to its mediator - we have to keep that mediator alive in the MediatorMap and watch for removal of the view comp in order to release it.

    Anyway, it seems to me that you actually do want to be using the Mediator Pattern ("View is passive and is not aware of the Presenter"), so perhaps hooking into preRegister will give you what you need to hook into the view components life-cycle properly.

    I hope that helps. Let me know if you need any other details cleared up - or, just let me know how you get along (I'm interested in this workflow).

    Cheers,
    Shaun

  2. Support Staff 2 Posted by Shaun Smith on 11 Dec, 2009 02:17 PM

    Shaun Smith's Avatar

    Actually, the "slightly naughty" approach probably wouldn't work too well - nothing will be holding on to that presenter reference, so it'd get eaten by GC at some point (if not immediately).

    Also, I didn't mention how to use the ViewMap:

    viewMap.mapType(MyViewComp);
    

    You can map concrete classes, abstract classes or interfaces with mapType. There is also the viewMap.mapPackage() method which allows mapping an entire package of view components (including sub-packages).

  3. 3 Posted by elad.ny on 23 Jan, 2010 05:10 PM

    elad.ny's Avatar

    I just created an implementation of RobotLegs using the Presentation Model that access entire component's events lifecycle:
    http://elromdesign.com/blog/2010/01/23/robotlegs-presentation-model...

  4. Till Schneidereit closed this discussion on 02 Mar, 2010 12:46 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