Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Registering Multiple Instances of one Mediator and Proxy: A Best Practice  (Read 26590 times)
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« on: July 30, 2008, 09:49:26 »

Say you have an application where you manage users. You provide a multi-tasking UI, using flexlib’s SuperTabNavigator to provide multiple tabs with each tab representing a user. Maybe its a form where they can edit that data or simply view it. You could expect to have at least the following classes:

  • User (MXML component)
  • UserVO
  • UserProxy
  • UserMediator

Now the problem becomes that you need to create multiple instances of these objects and register the proxies and mediators dynamically with PureMVC. Another problem is when one of these objects sends a notification that is specific to that instance it you need a way to ‘tag’ it. I’ve been using the notification’s type property for that. Cliff Hall and others have suggested the same.

 I figured setting and defining a best practice for consistency would help others. Let me describe what I have been doing in my PureMVC projects to achieve this in a clean, productive manner.

First I need to allow the constructor of a mediator and a proxy to take a dynamic name. The constructor would take the NAME constant as a default but you would always override it. So I would setup a UserProxy like this:

:
/**
 * Constructor.
 */
public function UserProxy(proxyName:String=NAME)
{
super(proxyName, new UserVO());
}

This way I can provide a unique name. The same applies to a Mediator. Next I would create an implicit getter to abstract the call to getMediatorName() or getProxyName().

:
//--------------------------------------------------------------------------
//
//  Properties
//
//--------------------------------------------------------------------------

//----------------------------------
//  id
//----------------------------------

/**
 * The proxy's unique id. This is a dynamically registered proxy.
 */
public function get id():String
{
return getProxyName();
}

The same code above applies to a Mediator. This provides for a consistent name and doesn’t have your proxy or mediator littered with getMediatorName() or getProxyName() calls whenever you are sending notifications.

Now for the actual creation of the objects I would have a command take care of that, this way its easily reusable and the all object registrations are in one place. Nice! As an example I would have a command named CreateUserEditorCommand and it would look this:

:
/**
 * Create a new User editor with its own mediator and proxy and then
 * we send a notification to add it to the set of tabs.
 */
override public function execute(note:INotification):void
{
var uid:String = UIDUtil.createUID();

var user:User = new User(); // this is our MXML component
user.label = "Cliff Hall";
user.id = uid;

facade.registerProxy( new UserProxy( uid ) );
facade.registerMediator( new UserMediator( uid, user ) );

sendNotification(ApplicationFacade.ADD_EDITOR, user);
}

The User instance is our MXML component (our editor tab) and if you look carefully I’m setting its id property to a unique identifier. I use the UIDUtil class (part of the Flex framework) to make sure I always have a unique id. The reason I set it on the MXML component is this way I have access to it there. This might not be needed.

I’m not sure if ‘id’ is the best name to be used here and hoping to get suggestions from all of you. I’ve talked about this approach with my fellow employees and they like it.

I had a suggestion from our Flex team leader to use the ‘name’ property instead of ‘id’ on the MXML component especially since Flex uses ‘id’ internally. I figured if I’m setting it with something unique though it shouldn’t be a problem. I have been considering instead using ‘name’ as the implicit getter on the mediator and proxy and on the MXML component.

Thoughts?

If this generates interest I’ll share how I register sub proxies and mediators as well as a command to clean up these dynamically registered actors.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 30, 2008, 05:51:44 »

I use "id". You're never going to instantiate a Mediator or Proxy in MXML so its not really a conflict.

And you've got it. a Proxy/Mediator pair can be created by giving them both the same unique name, and using that as the type property of Notifications leaving the Proxy. The Mediator instance uses type as a discriminator, only taking action if it matches its own name.

The getter for "id" is of course optional.

Good show, and thanks for the post.
-=Cliff>
Logged
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« Reply #2 on: July 30, 2008, 08:12:59 »

Cliff thanks for the support. It seems to have your approval so I'll make a blog post about it on www.arc90.com, where I work. We use PureMVC there quite heavily now. We build a lot multi-tasking apps so seeing SuperTabNavigator being used by us isn't anything new. I had to tackle this dynamic registration issue while still being quite new with PureMVC and Flex in general.

The part about the MXML component getting the same id set on its id property was in case you aren't currently in a mediator or proxy for that component. But even for the situation I was in I realize now I don't really need it. I was sending a notification containing the tab to be acted on by another mediator (ApplicationMediator) where it would remove the tab from the SuperTabNavigator. So I needed the id at the point to then fire a command to clean up (remove) the dynamic actors (mediator, proxies, etc.) for my component. But I could easily have made that sendNotification call within the tab's mediator.

Yes the getter for id is optional but I think its a good standard if you are doing this sort of dynamic registration. Not really sure what other term to coin here. Because if not you need getProxyName() and getMediatorName() calls everywhere and its not very easy to understand why thats there in a sendNotification call. Figured if I was passing an 'id' as the type I was 'tagging' or 'flagging' that notification to only be executed by a specific mediator if needed.

I'll follow up in the coming days with a post on what I do for registering more than 1 proxy with a component and a suggestion on good practice for cleaning up (removing the mediator and proxy instances).
Logged
openoli
Full Member
***
Posts: 44


View Profile Email
« Reply #3 on: September 22, 2008, 08:24:57 »

Hello JJfutbol,
thanks for this example !
I'm new in flex and pureMVC so I'd like to ask if you'd provide a full example implementation
of this concept.
That would be very helpful for me.

Many thanks in advance.

Olaf
Logged
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« Reply #4 on: September 22, 2008, 08:54:32 »

@Olaf

I've provided sample code in the first post. Honestly, its nothing more than that. It's pretty bare bones so I don't think a full example will be of much use. The trick is to knowing that you have to register that multi instance mediator and/or proxies with a unique name. All of the grunt work happens in the command.
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #5 on: September 22, 2008, 04:23:39 »

I do this like so:

:
public class MyProxy extends Proxy implements IProxy
{
        public static const NAME:String = "MyProxyName";
        private var instanceUID:String;

        public function MyProxy(instanceUID:String)
        {
                this.instanceUID = instanceUID;
                super(this.getProxyName(), new myVO())
        }

        override public function getProxyName():String
        {
                return NAME + "::" +this.instanceUID;
        }               
}

This way my proxy objects have a nice uniform prefix and their UID. It also eliminates the need to abstract the pureMVC paradigm of getProxyName(). Same concept, really, just a little less abstraction.
Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« Reply #6 on: September 22, 2008, 04:47:24 »

My problem with the getProxyName was the meaning wasn't enough. I hated having to see so many sendNotification calls with a third parameter of getProxyName and getMediatorName. I have had others look at me puzzled wondering what that does. I've been trying to find a good name like "actorGroupId" or "tag" something that you know when you set that third parameter of the sendNotification call its a bit more meaningful. All preference really.
Logged
openoli
Full Member
***
Posts: 44


View Profile Email
« Reply #7 on: September 24, 2008, 09:20:31 »

@JJfutbol
After studying the pureMVC docs, the forum and best practise infos I think I've got it.
My main problem was the deferred instantiation cause I've used the SuperTabNavigator as nested
component.

For anybody else who has the same problem (view comp is null by mediator registration ), here's the solution:
http://puremvc.org/content/view/91/185/
Many thanks to Cliff for the great documentation !

The "view part" of my DemoApp is working now so tomorrow I'll try to integrate WebOrb and
take a more detailed look at the proxies.

Thanks !
Olaf
Logged
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« Reply #8 on: September 24, 2008, 10:25:11 »

@Olaf

Great to hear everything has worked out. :) Re-reading the documentation certainly helps out a lot more. It has for me at least. If I had known that your problem was related to the SuperTabNavigator (I use that a lot here at work) I would have pointed you right away to the Slacker demo! Cliff has done an amazing job with that! It really helps understand how to handle deferred instantiation better.

Good luck with your journey into proxies! If you have more questions let us know. Always happy to help.
Logged
minhv
Newbie
*
Posts: 4


View Profile Email
« Reply #9 on: November 10, 2008, 12:43:58 »

JJfutbol could you post the code to cleanup proxies/mediator and registration of subproxies/mediators?

Thanks.
Logged
Pages: [1]
Print