What values can you store on a mediator?

[jamesmcness]

Hi I think this is a question that can be answered pretty quickly,

Like a lot of people out there pureMVC is really exciting me and I'm attempting my first project now. It's a very simple widget for a website that with have 3 slideout panels with each displaying different information. I have a mediator called the "TabMediator" which I am going to use to steward the tabs and their transitions.

I'm currently trying to work out where I should store information about which is the currently selected Tab. Can I store this as a value in the TabMediator, or do I have to create a proxy just to retain this one piece of information?

What's the thinking on deciding somethign like this?

Thanks in advance,
James

[puremvc]

That's a function of the TabNavigator component itself.

If the TabMediator has a TabNavigator as its viewComponent then the Mediator may access the public selectedIndex or selectedItem property of that viewComponent to ascertain the selected tab. If you wish, you can even create typed getters in the Mediator that return the selectedItem of the view component cast to its appropriate type.

But if you try to store that value as a straight property of the Mediator, now you take on the responsibility of keeping it in sync with the selected item on the component itself. Avoid this if possible. Mediators really shouldn't keep a bunch of properties, and particularly shouldn't be involved in keeping state. That is not one of their responsibilities.

-=Cliff>

[jamesmcness]

Thanks Cliff,
I understand what you're saying.

Does that mean the TabNavigator itself determines things like if a tab click should instigate a transition or not without consulting the mediator? (e.g. the requested tab is already open - so don't instigate a transition).

Maybe that makes sense, being a noob I was just cautious of putting too much logic into the platform specific side of the application and not within the main framework actors.

James

[puremvc]

The view component itself should encapsulate as much of its own behavior as possible. This means form validation, transition management, sub-component visibilty, etc.

The mediator is not a 'code-behind' class where you pile lots of logic. Ideally it simply mediates communications between the component and the rest of the app and visa-versa.

Lets say you create this swift custom Flex component and its really reusable. If the 'brains' are in the mediator, then you can only reuse the component in a PureMVC system. This is also why you don't want the view component to know anything about the PureMVC apparatus to which it is connected.

-=Cliff>

[jamesmcness]

Thanks again Cliff - makes a lot of sense.

[jamesmcness]

A quick question regarding the content data for the Tabs.

I usually work with XML to provide the content data for my View Components. Would you suggest that I get the Mediator (or a proxie) to convert the data into some sort of santised VO before passing it to my View Component, or is it still good practice to allow the TabNavigator to deal with raw XML itself?

[puremvc]

The Value Object pattern is a way of sending strongly typed data across tiers in an n-tier app. That includes across MVC tiers within a client or server app, as well as when transferring between the server tier to the client tier in the larger system.

Consider that today you may only have one Mediator with interest in this particular XML snippit, but later many Mediators and or Commands may be interested and then you have a mess. If your Proxy broadcasts XML then the burdon of understanding that XML's implicit schema (and being refactored when it changes) is spread over all the interested Mediators and Commands.

So, I would suggest instead creating a VO with a property that is the XML and with implicit getters and setters that use e4x to expose and modify the data. Create this VO at the proxy and pass it to the Mediator. This gives you the best of both worlds, Your Value Object carries the XML structure over to the view, and provides a strongly typed interface for modifying it that all classes that handle the data can work with. And it leaves you with one place to store the knowledge about the XML structure, which is the VO itself.

Here's an example:

:

/*
  Media Turbine
  by Cliff Hall <cliff@futurescale.com>
  Copyright(c) 2009 - Futurescale, Inc.
 */
package com.futurescale.mediaturbine.common.model.vo
{

[Bindable]
public class MediaItemVO
{
public function MediaItemVO( xml:XML )
{
this.xml = xml;
}

public function get id():String
{
return xml.@id.toString();
}

public function set id( id:String ):void
{
xml.@id = id;
}

public function get name():String
{
return xml.@name.toString();
}

public function set name( name:String ):void
{
xml.@name = name;
}

public function get filebase():String
{
return xml.@filebase.toString();
}

public function set filebase( filebase:String ):void
{
xml.@filebase = filebase;
}

public function get imagefmt():String
{
return (xml.@imagefmt.toString() == '') ?
".jpg" :
"."+xml.@imagefmt.toString();
}

public function set imagefmt( fmt:String ):void
{
// make read-only getter bindable
}

public function get art():String
{
return "assets/art/"+filebase+imagefmt;
}

public function set art( art:String ):void
{
// make read-only getter bindable
}

public function get icon():String
{
return "assets/icons/"+filebase+imagefmt;
}

public function set icon( icon:String ):void
{
// make read-only getter bindable
}

protected var xml:XML;
}
}

In this example you see that the values of the xml are made into bindable properties on the VO without need for any assembly process at all. And it shows how to get funky with derived and read only properties (see the imagefmt, art and icon accessors).

A Proxy could receive the corresponding XML from the server, construct the VO (passing in the XML as the sole constructor parameter), then send a notification.

An interested Mediator could take the VO from the note body, set it as a property on the view component, where the properties of the VO (as exposed directly from the XML via bindable implict getters) are displayed in the appropriate fields via binding.

And it works the same going back.

The view component sets the values in the xml via the implicit setters and then alerts the Mediator with an event when the changes should be persisted.

The Mediator responds by invoking a method on a proxy or by sending a notification that a command hears. Either way it simply plucks the VO from the view component and passes it on.

QED.

-=Cliff>