shauno, downloaded your zip file and I think part of your problem is that you should:

1) Don't try to remove the mediator from within itself. Generally in Mediators you should only be dispatching/responding to notifications and working with your view You should instead create a command for this and send a notification for the command.

2) Your CreateTestCommand is doing a lot of stuff. I simplified it down into 3 seperate commands:

• CreateTestCommand (instaniates a new mediator and adds it via the facade)
• RunTestCommand (simply send a new notification for POKE_TEST)
• RemoveTestCommand ( calls facade.removeMediator )

I modified your code and ran it as a flex application with three buttons that fired off each command respectively. The mediator never responded to poke after it had been deleted.

I zipped up the code and threw it on  my server so you can take a look at it:

http://nathanlevesque.com/codehelp/test_src_solution.zip

(the mxml file simply does the same as your Main.as script did, plus contains the three buttons which call facade.notifyObservers when clicked for the events that the above commands respond to)

Also, if you haven't already, it would be good take browse through the Best Practices:

http://puremvc.org/component/option,com_wrapper/Itemid,30/

Good luck, and if you need any more help, let us know!

I could also see views being used to render out HTTP request to XHTML, XML, JSON, etc. The Mediator receives an event containing Proxy data to render out an RSS feed. The Mediator sets the view's public properties based on the data. The RSSView then renders out the appropriate RSS in XML.

Using the view like that you could easily build a very robust and extensive CMS system. Once all your views have rendered their XHTML, you simply stop processing. You could even add Ajax functionality to provide user events to a server-side view.

The only thing would be, that having the view persist server-side would bog down the server. But since HTTP requests are stateless anyway, there's really no need too since the client knows its state.

EDIT: Just noticed you had suggested this in email yesterday. Don't mean to steal your thunder on it, but wanted to add this for completeness of the discussion.

It seems to me that a lot of the discussion was based on frustrations with Cairngorm, Yakov in particular. I think a more important thing to consider is does a particular framework (if one at all) increase developer efficiency by doing things such as decreasing the amount of refactoring that must be done for minor changes/additions.

The problem I have with framework-less application design is as Cliff mentions it all becomes spaghetti code. Even though in the article they advocate separating code into "model", "view", etc folders, it's really a case of taking one big plate of spaghetti and dividing it up. There will still likely be too much interdependence between components.

As great as Flex is, in essence its an ActionScript wrapper for Flash. It divides things up into either MXML, AS3, or a mix of the two. As far as I can see it gives us some nice UI elements and some nice data interaction objects (RemoteObject, HTTPService, etc.). I consider Flex to be more of an API than an application framework, thus the need for a third party one.