Events. Push or pull data?

Alex's Avatar

Alex

11 Jan, 2011 04:55 PM

Hi.
Can't decide how to transfer data from model to view. I like data-push, because it makes view more independent (have not to inject model in Mediator). But the problem is I have to create event class for each passing data... or pass all data even if only 1 is needed. Data-pull looks better in this case, I think.
What method do you use?

  1. 2 Posted by Stray on 11 Jan, 2011 05:06 PM

    Stray's Avatar

    I almost always use push. The model is informing (via an event) that its state has changed, and offering a new snapshot for interested parties.

    There are two situations where I use pull:

    1) Where I have more than one instance of the same view and I want to only refresh this one (imagine a grid of news stories and being able to click a 'change' on any one story to get a new one instead).

    2) Where the view arrives after the model has last dispatched a state change.

    In the first case I use a sync-signal request-response pair. Basically I inject into the mediator a 'request signal' which has been mapped to a command. The argument for the signal is another signal, which requires the model's vo as an argument. The mediator creates this response signal and dispatches it on the request signal. The command is fired, grabs a vo from the model, and uses the response signal which the mediator passed as an argument to send this vo back to the same mediator that fired the request.

    In the second case I now use an implementation of the eventMap which I call the 'relaxedEventMap'. It basically allows you to keep event history and get the last instance of the event, so that the view can arrive after the model last updated and pick up the event that the model last sent. Effectively this is a pull, but the pull is wrapped in the relaxedEventMap and is being executed in there, pulling from its history.

  2. 3 Posted by Alex on 11 Jan, 2011 05:23 PM

    Alex's Avatar

    Thanks for your answer.
    "The model is informing (via an event) that its state has changed, and offering a new snapshot for interested parties" - so do you create event class for each state?

  3. 4 Posted by Stray on 11 Jan, 2011 05:33 PM

    Stray's Avatar

    I don't have a golden rule - it's all about what's needed / appropriate.

    If a model is capable of dispatching 2 different kinds of VO then it's likely that I would create two different event classes, each of which requires the correct type of VO.

    Finding bugs is always slower than just typing code, so if an extra class is what it takes for the compiler to stop me from making a stupid mistake then that's fine by me.

    However - if the model always dispatches the same type of VO then chances are that it would only require one event class, though that event would carry different types.

  4. 5 Posted by Alex on 11 Jan, 2011 10:19 PM

    Alex's Avatar

    Can you explain me on an example http://insideria.com/2010/06/an-introduction-to-robotlegs-a-1.html ?
    ------------------
    private var _selected:Author;
    public function get selected():Author
    {
       return _selected;
    }

    public function set selected(value:Author):void
    {
       _selected = value;
       dispatch(new SelectedAuthorEvent(SelectedAuthorEvent.SELECTED, selected));
    }
    -------------------
    Would you behave likewise? What if I have another "selectedField" in that model? Should I create SelectedFieldAuthorEvent?

  5. 6 Posted by Sebastian Servat on 12 Jan, 2011 11:24 PM

    Sebastian Servat's Avatar

    Personally, I would create an array and push all selected instances. Then dispatch a unique event with the array as the 2nd parameter. It's more dynamic and loose-coupled.

  6. 7 Posted by Alex on 13 Jan, 2011 06:52 AM

    Alex's Avatar

    selectedField is of another type than Author and have nothing in common with Author.

  7. Stray closed this discussion on 13 Feb, 2011 03:53 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