Like I said in the past, the Mediator for PureMVC is great. It’s the most popular interpretation/implementation of the P in MVP I’ve seen for Flex/Flash. The majority of my View’s now just retain state, and the code for them is significantly reduced (sometimes totally) to just handle state and user interactions. No additional application/business logic, no “simple Mediator” type code; strictly showing VO’s, changing state, and responding to user interactions & data changes. That’s just awesome. Anything that can reduce the amount of code in my View’s, ride on top to handle being the liaison to the service layer and sometimes other View concerns just “feels” great.

Again, it all comes down to being an OOP Purist and refusing to let your View’s know that they have overloads that really control their destiny. If that’s your stance, yes, this technique is not useful, and offensive. To the Pragmatists who use PureMVC, Cairngorm, or any other framework, it’s a helpful way to leverage to an AS3 feature.

Saying,”I use puremvc_internal namespaces not to couple my View’s to my PureMVC Mediator’s, but rather clearly define the relationship. This relationship was planned, and isn’t going away.” is contradictory to me because a relationship that is planned and isn’t going away is the definition of tightly coupled.

I don’t think that your approach is wrong, but you no longer have true Mediators. As long as you are making your views framework aware, why not take it a step further and do away with the Mediators altogether?

Rich: I hope so!