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

Show Posts

* | |

  Show Posts
Pages: 1 2 3 [4]
46  Announcements and General Discussion / General Discussion / Re: Nested View - Manage Mediators. on: August 17, 2008, 11:15:41
Cliff,

Thanks for making it into an FAQ entry! This will come in handy. But where do we find the entire FAQ on the site? I can't seem to find it anywhere.
47  Announcements and General Discussion / General Discussion / Re: Nested View - Manage Mediators. on: August 05, 2008, 08:18:03
@yeremy

I highly recommend Cliff's posts in the following topic: http://forums.puremvc.org/index.php?topic=280.0 His code examples are a great help for solving the problems you are having. They have really helped me out.
48  Announcements and General Discussion / General Discussion / Re: proxy, mediator notification problem on: August 05, 2008, 08:14:36
To help out with this I've covered in a post too on some best practices for handling registration of multiple instances of a proxy/mediator. Check it out and let me know what you think: http://forums.puremvc.org/index.php?topic=596.0 I'd like to expand it because I think this would help solve a lot of how-to questions.
49  Announcements and General Discussion / Architecture / Re: Registering Multiple Instances of one Mediator and Proxy: A Best Practice 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).
50  Announcements and General Discussion / Architecture / Registering Multiple Instances of one Mediator and Proxy: A Best Practice 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.
51  Announcements and General Discussion / General Discussion / Re: 5 reasons PureMVC kicks ass on: July 08, 2008, 11:20:25
I come from the world of ColdFusion and I have always wanted to do Flex/CF development. One of the main reasons I took a new job in NYC at Arc90. I have a lot of experience with CF frameworks such as Model Glue and I wanted something in place that I could follow and after looking at PureMVC I knew it was the framework for me. Since a lot of the same concepts carry on over the time I spent was getting really comfortable with Flex itself rather than the PureMVC framework.
52  Announcements and General Discussion / General Discussion / Re: normalizing remoteObjects on: July 08, 2008, 11:01:11
I have some questions on this approach though. Say you wanted in a View component to display in a List with a custom item renderer all books with their creation date, the author name, etc.

How would you go about getting the author name (or any related author data) for that type of view?

I get lost in that part because if you have a BookVO but it only has an authorId property rather than a complex property called author (being an AuthorVO) what do you do?

Do you create a new arrayCollection in the mediator for that view? But you can't add BookVO's since you need the author data. Curious to hear your thoughts as I've struggled a lot with this. Again, thanks for all the great comments!
53  Announcements and General Discussion / General Discussion / Re: How to get configuration data to proxies/delegates on: July 08, 2008, 10:47:25
This is a great question and wanted to share what I do. In this case from the Proxy I would pass along the URL to the Delegate that it should use. This way if the Delegate will point to a new service it will need some sort of URL, whether its a dot notation path to a CFC (ColdFusion Component) or say a HTTPService.

Once I've loaded up the configuration I actually place it in the ApplicationFacade since I need it easily accessible by the entire system. It drives a lot of different parts of an application so figured the best place for that was as a property in the ApplicationFacade. Curious to hear what others have to say as well.
Pages: 1 2 3 [4]