Posted on by JesterXL

1 vs Many, Mediator vs Presenter, 30 mins – JXLTV – Episode #1


			
			
			
			
				JXL TV Episode 1

Jesse talks about 1 class vs. many classes, the Mediator vs. Presenter pattern contest on Twitter, & the 30 minutes a day tactic.

Mentioned links:

13 Replies to “1 vs Many, Mediator vs Presenter, 30 mins – JXLTV – Episode #1”

  1. Jesse,

    I enjoyed your video twice:

    1. Listened to your preso as usual. Good stuff.

    2. Turned off the sound in your video player and turned on the sound of Pink Floyd’s Another Brick in the Wall while watching you. This run was less informative, but more fun :)

    I hope you want get angry with me for this comment – you know I really like and respect you!

  11. Tell me if I’m wrong, but I am sure you explain the differences between presenter/mediator then you recap, but you switch the differences! Did anyone else notice?

    This is in reference to “talking to multiple views” or “one view”.

  12. Yup. The definitions of Presenter & Mediator in “the Flash world” are muddied, and I apologize doing it myself whilst drinking. Some people follow Martin Fowler’s definition of treating like the logic engine for the View. Other’s call it a Mediator even though it’s a Presenter. Some frameworks take their own spin on it. Basically, Mediator & Presenter can mean any variation of “Controller” as you want.

    Suffice to say, Presenter handles all the logic in the View, where as Mediator is supposed to be the View’s gateway to talk to others.

    A Mediator isn’t supposed to “hold the View’s logic” although in smaller apps, he often does in the case of Mediators in PureMVC or Robotlegs. For some, they take it a step farther and clearly define the responsibilities, like Elad’s Presenter Robotlegs example.

    So, while Presenter isn’t abused a lot, Mediator is… because in Flash, Mediator’s basically are Presenters in a lot of implementations I’ve seen.

    For example, PureMVC & Robotlegs both “typically” have 1 View injected into the Mediator. Yet… the “Mediator” holds a lot of logic for the View, and allows it to communicate to other View’s via Notifications/Events. MOST implementations I’ve seen are like this. However, these “Mediators” suddenly take on a LOT of the View logic… thus making them act more like Presenters.

    Read Elad’s article, that may give you another perspective. OR, check out how people are using the Passive View in Swiz. That’s a more evolved pattern that is especially suited to Flex devs who are wanting more guidance in their code behind implementations. Ben, who works on Swiz has one, and Brian Riley has a Part 1 and Part 2 example as well.

Comments are closed.