Why a use signal for view to mediator communication?

eddie.amphlett's Avatar

eddie.amphlett

21 Jul, 2011 10:15 AM

I have a dropdown list in a view which contains references to a number of playlists. On selection of one of these I want to send a signal with the id to use a command to grab the right playlist from the model.

It seems a bit messy to go injecting signals into my view to dispatch directly form there, so I'm selecting in the view, then dispatching from the mediator.

In my view I'm creating a new signal (not mapped to anything so as to keep the view separate from the framework) to which the mediator listens and will then send another signal which is mapped in the framework and will retrieve the correct playlist.

This all seems a bit like making extra work though, having two PlaylistSelcted signals, one to let the mediator know it's been made, and a second to let the framework know which one has been selected. Is there any real benefit of me making the extra signal class to communicate between the view and mediator this way? Or should I just use an event listener in the mediator to listen for a selection and just have the one signal which is dispatched from the mediator? Or shall I forget about the messiness and inject the signal into the view so I can dispatch to the framework from there and bypass the mediator all together?

  1. 2 Posted by Stray on 21 Jul, 2011 10:23 AM

    Stray's Avatar

    My view -> mediator signals are just vanilla signals that are properties of the view. The fact that the mediator-view relationship is 1:1 means you don't need to further identify it with a class for injection - just expose it with a getter.

    So - your first signal can be simply

    new Signal(somePropTypes...)

    Does that make sense?

    Definitely don't inject the signal into the view.

    Stray

  2. 3 Posted by eddie.amphlett on 21 Jul, 2011 10:40 AM

    eddie.amphlett's Avatar

    I think so. So if I include the signals path I'd create the signal in my declerations tag with

    <signals:Signal id="playlistSelected" />

    And then from my dropdown list dispatch it with

    <s:DropDownList id="playlistDropDown" change="{playlistSelected.dispatch(playlistDropDown.selectedIndex)}" />

    ??

    This works and seems cleaner straight away. But when you say my signal can simply be new Signal(somePropTypes...), are you suggesting I can create the signal at the time of dispatching it rather than in two steps?

  3. 4 Posted by Stray on 21 Jul, 2011 10:55 AM

    Stray's Avatar

    Hi Eddie -

    I was suggesting you create the signal as a property - as you have here, except that you'll need to declare the return type so that you can send that selectedIndex property in the dispatch. I'm afraid I'm a pure-as3-only girl so I don't know the mxml equivalent of new Signal(uint)... but I'm sure you do.

    Stray

    On 21 Jul 2011, at 11:39, eddie.amphlett wrote

  4. 5 Posted by eddie.amphlett on 21 Jul, 2011 11:03 AM

    eddie.amphlett's Avatar

    Cool. It all seems to be working fine and is looking lots tidier.

    Thanks very much,
    Ed

  5. 6 Posted by Michal Wroblewski on 21 Jul, 2011 12:27 PM

    Michal Wroblewski's Avatar

    Hi Eddie.

    Your second attempt is ok. You just did what Stray meant. In declaration field you introduced a property (after compilation it's converted to getter/setter. She also suggested you to introduce value classes - type of dispatched values. You can also do it in MXML like this:

    <signals:Signal id="playlistSelected">{int}</signals:Signal>
    

    All MXML notation for Signals are stored here.

    And just one tip from me. If your view dispatches the same type of values as mediator injected signals you can assign injected signals in Mediator to your view instance. It should be done in onRegister. Then you don't need to listen and dispatch in Mediator. But you should remember that the instance of signal previously created by the view will disappear.

    I hope it's clear :)

    Mike

  6. Ondina D.F. closed this discussion on 02 Nov, 2011 05:36 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