Joel, I like that usage - it removes some of the guesswork, especially if several developers are involved. I actually thought that's what the parameter's intention was (going from the name too) but then saw other examples that worked in a different way.

Cliff - I understand what you are saying. At the moment it's a little hard for me to see the benefit as it just seems to increase the knowledge you need to have about each notification. I guess it's a matter of providing thorough documentation.

cheers - Nils.

Hi Cliff,

thanks for the quick reply. I don't remember where I read it - maybe I remembered incorrectly or it's just something I wanted to do on my current project. I'll let you know if I come across it again somewhere.

In any case though, what are your thoughts on garbage collection for mediators that aren't used anymore? They usually listen to events from view components, so references are likely in more places than just the PureMVC framework. We could use weak references when adding event listeners in Flash/Flex - but I reckon it would be nice to have a function that can be overridden when the Mediator is removed.

I'm just getting in to all this - sorry if it's already been discussed elsewhere.

- Nils.

Hi there,

I read in the best practice guide that you should call a 'destroy' method before removing a Mediator from the Facade. This of course makes perfect sense, since a removed Mediator probably has quite a few view component dependencies that need cleaning up.

My main question is - why isn't that 'destroy' method part of the architecture?

Second question: Is there a chance in future updates that 'removeMediator' could return the instance that was removed? At the moment, to call 'destroy()', I need to retrieve the instance, then call destroy(), then remove the instance, whereas it could all go into one line:

facade.removeMediator(name).destroy();

Or am I missing something important?

cheers - Nils.

Hi all,

very simply put:

- what is the Notification 'type' property for?



cheers - Nils.