Reusing components as subcomponents / dynamic mediators

[Don-Duong Quach]

I'm having difficulty grappling with a scenario where I have designed a component and a subsequent Mediator for it, then down the road I need to reuse that component as a subcomponent.  It seems like I have no choice but to create a new Mediator class that can deal with the multiple subcomponents. 

A concrete example would a video player application that displays one window for one video.  Then down the road say I want to reuse that video component inside of some tiling component so multiple streams can be displayed simultaneously. 

My first inclination is to create a wrapper Mediator that manages the video display Mediators.  In essence this is what a typical ApplicationMediator in the PureMVC demos, but each of the components are unique. 

In the same way, I'd like to manage multiple instances of one component, but the way Mediators are registered right now I can only have one instance of any given Mediator. 

Does anyone have a good way to approach this scenario?

[puremvc]

Don,

In the example you give, there are a few possibilities that come to mind:

Multiplicity
You might go with multiple instances of the same VideoPlayerMediator. The idiom of using a constant for the Mediator name won't work though, and you'll have to dynamically give the Mediator a name. Dynamically-named Mediators can best take their name by appending 'Mediator' to their View Component's instance name. The Rather than having a constant NAME, the Mediator would have a private name variable, which it sets at construction time based upon its View Component's id. Then in getMediatorName, we return this property. (Multiplicity in Mediators will be covered in the upcoming courseware).

Uber-component/Mediator
Make the tile component that holds the multiple video components be a custom component that passes events from its children to its Mediator. The Mediator for the tile component knows about how to deal with the video components it contains.

The first one is probably the best option since it would be more reusable.

-=Cliff>

[Don-Duong Quach]

Thanks for the reply Cliff.  I thought of the idea of using an internal id after I had posted, but it's good to get confirmation from someone as experienced as you.

[danieleUg]

Hi Cliff, hi Don

I have a similar situation, I have a component that can be reused in more parts.
I have made a little experiment I would like to have your feedback and how this case can fit better in the framework.

In my solution the component create own Mediator, the problem is how remove the Mediator when the component end his live, I have tried with FlexEvent.EXIT_STATE and FlexEvent.REMOVE events but witout success.

The code and compiled swf cn be downloaded here:
http://dev.ugoletti.com/puremvc/DynamicMediator.zip

[puremvc]

Daniele,

It is not a good idea to have the View Component create or even know about its Mediator. This makes it less portable, and ties it to the PureMVC implementation. Ideally, View Components should know nothing about the PureMVC system and communicate with it solely by exposing an API consisting of Events and public properties.

In order to closely coordinate a transient popup with a View Component, a good solution is to have the Mediator fully manage the existence of the popup.

In your example, MainScreen.mxml should send an Event instead of the creating the popup.

Then the MainScreenMediator should create the Popup and keep a reference to it in a separate instance property, (i.e. private var popup:MyWindow).

When it creates the popup, it should listen for Events from the popup as well, such as MyWindow.CLOSE, which would be sent by MyWindow when the 'Close' button is clicked. The Mediator would respond to by destroying the popup.

There would likely be other Events that the popup would send as well, such as MyWindow.ADD, or MyWindow.UPDATE, sent when the user clicks an 'Add' or 'Update' button. The Mediator would respond to these by taking the data exposed by the popup (or sent in a custom event), perhaps sending a Notification that triggers a Command to update the model, and finally, closing the popup.

There could be a separate Mediator for this popup if its used in multiple places, but if it's tied to interaction with this one View Component, it makes sense to have the Mediator do double duty of managing its primary View Component as well as its associated popup.

In any case, the transient component should be created, listened to, and destroyed by a Mediator.

-=Cliff>

[danieleUg]

Cliff,
I see your point, but let me know if I have undestand all, we can have differents cases to cover:

-1. in the screen we have two instance of the same component and it can be used in more screens. All components instance must have own Mediator class. The Screen Mediator create and register the new Mediators for the all components, each will have different name.

-2. I have a button that create popup window that can be used in more screens, the Screen Mediator create the popup and register the new Mediator.

-3. at the end there are cases when a component or popup don't need own Mediator, because can be controlled by screen mediator.

I think that a example that cover all will be very usefull for the people that just learing PureMVC.

Daniele

[puremvc]

Good summation, Daniele.

That's essentially it. And I will make sure in the courseware to illustrate these cases as well.

Thanks,
-=Clliff>

[danieleUg]

Cliff,
I just try to code all the above cases, but in all I see some disadvantage. First of all what's the goal of this discussion: have reusable components with own Mediator.

Now if you try to code cases 1 and 2, you will see that there are a lot of Mediators code duplicated.
For example: MyComponent is a component that I use in a lot of popup window, each time that I open a window I have two solutions:
- the screen mediator open the window  and create a Mediator for the windows, and it create a MyComponentMediator. But if I don't need the Mediator for the window, I must to add a class only for create MyComponentMediator.
- the screen mediator open the window and create a Mediator for the component that is inside the window.

I think that the second solution is better, but why duplicate the code for register the mediator?
I understand your point that pureMVC is hidden for the components, but at the same time I think that to have the way for autocreate the mediator for reusable components can be a cool feature, how make this? I don't know, the only solution that I have found (for now) is the example that I have posted.

Daniele

[puremvc]

Daniele,

Sorry, I mistook your #1 in the previous post. Each instance of the reusable component needs its own Mediator instance. Not a separate class.

And with #2, if multiple classes need an assocated popup, you can create an AbstractPopupMediator (extends Mediator) that handles popup management. Then each concrete Mediator that needs to also have a popup can inherit from AbstractPopupMediator.

-=Cliff>

[danieleUg]

Cliff,
thanks I must to start to code for found the right way for all the cases .... but I will do after my vacation that start tomorrow.


Daniele

[puremvc]

Daniele,

Have a good time on vacation. I vaguely recall what that's like

-=Cliff>

[francois]

Hello,
I know tis topic is quite old but I made a demo on my website and I'd like to see if this is correct ;-)

You can find the post at
http://blog.loadvars.com/2009/07/07/using-multiple-instances-of-the-same-mediator-in-puremvc/

Demo
http://files.loadvars.com/puremvc/multicore/multiplicity/

View source
http://files.loadvars.com/puremvc/multicore/multiplicity/srcview/index.html

Cliff, is my example correct ?
Feel free to use it and keep up the good work

[Jason MacDonald]

Demo and view source are dead links.

[francois]

Sorry for the inconvenience 
But now it should be working now, please have a look 
So does that code looks good for you ?

[puremvc]

You can skip making the name variable and also the overriding of the getMediatorName method. This should be sufficient:

:

public function PartnersMediator( viewComponent:Partners )
{
   super( viewComponent.id + 'Mediator', viewComponent );
}
-=Cliff>