Sean,

The use of getMediator, and in fact the need for a Mediator to have a name at all is really only owing to one rarely used situation.

There is the case when we want to have one Mediator instantiate another in a place other than its constuctor, as a result of the deferred instantiation of a viewComponent.

For instance, an application might have a TabNavigator with creationPolicy="auto", so only the first child is created at startup. When the user navigates to a new tab, the child is created. The app sends an Event which the ApplicationMediator  responds to by creating and registering the new Mediator. But this should happen only the first time. So before creating the new Mediator, it calls retrieveMediator to see if it exists yet. 

Otherwise, Mediators really don't need names except in as much as they help us in the debugger.

This and more will be shoing up in a FAQ soon.

As always, thanks for bringing it up and forcing a little light to be shed on the subject.

-=Cliff>

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,

It is true that there is rarely a time when you would want to call removeMediator. However, when you are writing a framework, it's difficult to predict everything people will try to do with it.

I did not want to rule out the possiblity that someone would want to dynamically register and remove Mediators, even though my tests and thinking on the subject at the time had pretty much led me to think it would be rare.

In coming FAQ's and the courseware, etc, I'll elaborate, but for now, at least if you do decide you want to do this, it won't ever cause a problem.

-=Cliff>

Don,

You're absolutely right, the associated Observer instances were not being removed from the View's observerMap when removeMediator was done.

I have corrected the problem, and updated the framework and unit tests. The new framework version is 1.5 and is now the currently downloadable  version.

Since removing Mediators after their creation is seldom done and not really advised (see earlier in the thread for those just tuning in), this is not something that will change the behavior of any existing application or require any recoding. 

The change entailed adding a compareNotifyContext method to Observer and IObserver. This allows the View to compare the Mediator being removed to a given Observer's Notification Context reference without breaking the Observer's encapsulation of that reference.

The removeMediator method of the View now goes through the observerMap (where notification name is key and an array of observers is value) and for each observer list, removes the Observers pointing to this specific Mediator reference. If this causes the Observer list length  to fall to zero (no more observers for this notification name), the reference to the observer list is set to null, freeing it as well.

The Unit tests have been updated to test the new Observer.compareNotifyContext method.

Below are screenshots showing before and after a removeMediator test in the debugger. They show that the Observers are removed, and further, when the last observer in an observer list is removed, the list itself is removed.

Before


After


Note that the keys still exist in the array; both for removed Mediators and for Notifications that now have null observer lists.

Though the keys remaining are tiny and few, the act of adding a Mediator then removing it should be idempotent; it should, as a good nature hiker, leave no trace.

However, I've found no good way to remove the keys of an associative array other than to copy the array elements over to a new array, bringing over only the ones that are not null, then replacing the original array reference. The splice method only works for strict arrays, these are associative arrays.

Copying the arrays is the answer, but I'm not yet decided as to whether to have a cleanup function or to do it inline. This is an minor optimization that will be thought out and included in a future maintenance release.

Again, thanks for catching this and bringing it to my attention. The plan is to push the framework to an extremely stable state quickly and not touch it anymore. While this wasn't a fatal flaw, finding and dispatching any issues early on is the name of the game.

-=Cliff>

Don,

The automagical registration of Mediators was added in a late iteration of the framework.

By that time, patterns of usage were emerging in tests that suggested that we would typically handle transient View Components such as popups or seldom used panels by having a long-living Mediator that is responsible for its creation and removal.

The Mediator's instantiation might be deferred, but once created it would manage the existence of the transient component throughout the remainder of runtime. Otherwise we incur double object creation time costs each time the component (and its Mediator) are created.

The Mediator instance has a relatively miniscule size, owing to its simplistic role. So to the question of leaving the Mediator around after it is created or to incur the time to create another new one if you happen to visit the seldom used View Component again, I'd almost always advocate the former.

This means subsequent removal of Mediators is not really expected, though it should work.

I will test this, and it may result in a maintenance release if the Observers are not being removed from the observerMap on removeMediator. I am going to move this thread to the Bug Report forum.

Thanks,
-=Cliff>

Daniele,

I will be happy to help with getting some documentation together and present it here as a demo people can actually get started from. It might be helpful to create a second demo based upon this one, to show the direction someone might take to use it.

You can email me at cliff@puremvc.org

Also, I see you're using Flash Develop. I haven't tried it yet, but it looks good. Did you use Michael Ramirez's PureMVC Project plugin?

-=Cliff>

Daniele,

You've really done a great job here! It looks like something people could build off of pretty easily.

Here are my suggestions:

• Zip the project folder rather than its contents, so when someone unzips it, they get one folder, and don't have to create one first. This cost me a Version point on PureMVC 

• Move the business package under Model. Only a Proxy talks to it, so it shouldn't clutter the namespace at the MVC level. (the CafeTownsend demo has it at that level to make friendly with the Cairngorm folk, but it's not really a recommended practice I'd want to perpetuate with PureMVC.
  
  The Model tier is roundly in charge of communicating with remote services if necessary. It could be done inside the Proxy, as with CodePeek, or with a Business Delegate, as you've done here, but either way it will happen within the Model tier.
  
  Further, the Delegate pattern is only really useful to us if multiple Proxies will communicate with the same service the Delegate talks to, although it's not improper to use it if only one Proxy talks to it. It's a good division of responsibility, and I'm not suggesting its removal, only noting here for posterity that a good way to begin an app is to have the service logic inside the Proxy, and then later refactor it into a Delegate at the first call for reuse.
  
  One goal of the framework is to promote a 'simple as possible but no simpler' approach. Fewer actors will help newbies to design patterns and n-tier architecture grasp what's going on faster.

• And for the same reason, move the flex/helpers package to  model/helpers, since it is the Proxies that use it to parse their data files.

Again, Daniele, you did a super job here. The implementation of the StartupMonitorProxy is especially well done illustrating the use of data from the first loaded file affecting the subsequent calls.

If you wouldn't mind writing a little something about it, I'd love to feature it as a demo. It would be most helpful for people to get a feel for how to turn it into their own thing.

-=Cliff>

Daniele,

Sounds great, where can we see it?

-=Cliff>

Seb,

Yes, you can create a class extending MovieClip set it as the Document Root class and initialize the Facade from there. Or could instantiate it on a MovieClip instance on the Stage if the movie is going to be timeline based.

Your major concern will be in how to prepare the View.

In an MXML application, the Application object takes care of building all the initial View Components, and they're alive and waiting to have Mediators connected to them by the time you send a Notification (on creationComplete) to prepare the Model and the View.

This needs to happen differently in Flash. I will put a example online soon, I promise! 

-=Cliff>

You're absolutely right in your reasoning for using custom Notifications. In Flash, you're forced to extend Event if you want a payload, and knowing that some people really don't like having to create the extra classes, I felt it was the right thing to have the base Notification class have a Object payload, but support subclassing if you want to.

As for where to put them, I believe that adding the Notifications at the same level as ApplicationFacade makes the most sense. They have to live somewhere, nothing else is expected at that level, and they are potentially shared by all 3 tiers. That was the reasoning for putting the ApplicationFacade there.

Adding another branch at the MVC level is not really advised. The Cairngorm package structure forces only 2 more folders on you at the MVC level, but every time I find myself at that folder level in a drill down, I find I have to stop and think. Only for a second, but it adds up.

See this related discussion:
http://forums.puremvc.org/index.php?topic=8.0

-=Cliff>

Seb,

You'd just want to use removeCommand and removeMediator when you are done. Note that removeCommand is not on the IFacade interface, it's not something you'll do a lot. You can implement it on your ApplicationFacade, though, and still not have to make a call to the Controller.

-=Cliff>

Steve,

That's because it's been updated for Flex Builder 3/Adobe AIR. I hated to have to do that since so many people are still on FB2, but Adobe pretty much forced my hand, because they got rid of the Apollo Runtime.

But you can install FB3 (Moxie) on the same system with FB2 and not have any issues.

-=Cliff>

You have it just right. Retrieve the Proxy from anywhere, and act upon the methods and properties you choose to expose for manipulating and referring to its Data Object.

A Proxy should talk to FDS and expose a getter cast to ArrayCollection that your Mediator can retrieve a reference and set as a property on its View Component, which is in turn has, for instance, an editable DataGrid's dataProvider bound to it.

-=Cliff>

Jens,

This is really cool! Particularly for large patterns like the one with the roses, where the pattern shows up looking like ASCII Art in the CSS file making it obvious what's been done. Looking at the code, it seems you've really worked out how to apply the framework to your problem. Excellent!

I would only make one small suggestion. People often want to unzip to the desktop, yeilding one folder to point their IDE to. So, in your source code zip file, you might want to zip the project directory itself. Otherwise people have to create a directory to put the project in and unzip it there. I made this mistake with the very first release of the PureMVC source code.

-=Cliff>

Seb,

One of the early decisions made in the PureMVC Requirements was that it would be implemented in pure ActionScript and not rely upon any Flex or Flash classes. Dictionary is flash.utils.Dictionary, and was therefore off limits for the implementation.

However, this doesn't mean that zombie objects will ultimately overpower your machine. There are several reasons for this.

Firstly the Flash player uses a combination of two garbage collection methods: Reference Counting, and Mark and Sweep. In reference counting when the number of objects holding a reference to the object drops to zero it is available for collection. However this doesn't always get rid of everything that *should* go. You could have two objects that should be collected, since nothing else points to them, but they point to each other, and thus keep each other's ref count from hitting zero. Mark and sweep comes in and cleans these dust bunnies up.

Secondly, and more importantly, the use of arrays inside the framework is generally static with very little change after application startup. Why?

1) Because your Command mappings generally don't change dynamically. They represent your application's Use Cases. How often do the Use Cases for an application change at runtime? It can be hard enough to get them pinned down at requirements gathering time...

2) Proxies are almost always initialized at startup (even if they delay the instantiation of their data objects until accessed), and do not change.

3) The primary Mediators for the application are usually initialized at startup as well. Occasionally a Mediator's creation will be deferred until the user navigates to View Component that has had its instantiation deferred. But once instantiated, the View Component and the Mediator usually need to hang around for the rest of the application runtime.  If the View Component is transient, like a popup, then usually one Mediator is instantiated to handle it and it deals with creating and destroying the popup.

So, the upshot of 1, 2, and 3 is that even if GC failed us, PureMVC's array usage patterns don't lend themselves to runaway object buildup syndrome.