Have you tried reflexive mediator registration in Fabrication? It solves the problem of deferred mediator registration in a very simple way using component resolvers. Instead of waiting for the component to be created, you just register the mediator as you would. Fabrication waits for the component to become available and then registers the mediator with the facade. Check it out here[1].

peace,
darshan

[1] : http://code.google.com/p/fabrication/wiki/ReflexiveMediatorRegistration

Thanks for stopping by and adding!

I generally defer the creation of the Mediator until its view component exists. The way you’ve done it here illustrates what what the ApplicationMediator’s job usually ends up being.

You can send a bubbling Event (no need for a custom event really) from any depth within your view hierarchy in the creationComplete for your new view component, and then grab it at the top with the ApplicationMediator.

The event will have a reference to the component (event.target), which you can inspect any property of (such as id) in a switch statement, creating the appropriate Mediator depending upon the component and register it.

-=Cliff>

I wonder if the Factory Pattern could apply here. Could I build a mediator factory (or would that be an Abstract Factory). The idea obviously is that the factory would handle all the dirty work.

Or maybe some sort of dependency injection where display objects are injected into mediators at runtime so when display objects are added to the display list the mediator is already bound to them.

Food for thought anyway.

1. You could use a custom event subclass dispatched by the “removed” or “removedFromStage” event. The process here is almost exactly the same as in my post with the exception that you would call “facade.removeMediator(componentName)” from the listening mediator instead of creating a new mediator.

2. When you initially create the mediator, in the constructor method, add an event listener for the “removed” or “removedFromStage” event. Depending on which event you use your mediator will be notified just before it’s about to be removed from the display list. You can then have your mediator destroy itself.

I’d probably use method #2 most of the time. Method #1 is a bit overkill for most apps. Besides that method #2 requires your view component to dispatch one less event, which is always good.

“And people thought Cairngorm was complicated”

I think its great pureMVC jumps the gaps between Flex and flash and the server side stuff. But I honestly cant imagine implementing all this stuff in a large application.

I am excited to hear more of your reviews of it. I want to know if when you are done with a big project (something that warrants a heavy duty framework) if you feel all this stuff was worth while.

Thanks for the post!

What would be the best way to remove a mediator using the ComponentDestructionEvent… I’m trying to figure out how to get the ApplicationMediator to figure out what component just went out of view… and what mediator to take off.