I've been building apps in PureMVC for over a year now, and it still bothers me that you can only map a single command to any notification.  I don't follow the logic in this decision.  The Observer pattern, on which event driven architecture is based, should allow multiple parties to uniquely and independently handle any one event.  I find this enormously restrictive that mapping a notification to a command will overwrite a previous mapping.  I would prefer being able to target the removal of a mapping based on the Notification/Command pair.

I don't feel macro commands are the answer either...if I want to allow one command to be fired on a given notification consistently throughout the life-cycle of the application, yet during a sub-cycle ALSO handle the same notification in some other way, I should be able to do so based on the Notification/Command pairing.  In the AS3 event model, you removeEventListener based on the pair of Event to Function signature, allowing other handlers to remain intact on the Event.

Why the restriction?

Hello,

Been buried in PureMVC for 8 months, and fully entertained!

I'm wondering if anyone can point me to any example applications or tutorials (besides the Cheese one) on a PureMVC multicore application loading/unloading Modules and communicating from Shell to Module via Interfaces, not Pipes?

I'm writing AS3 only apps, non Flex, etc.

I'd really appreciate any examples! I need to review structuring a project to have a Shell (main-core) application, and Module (other cores) applications, and interfaces for communication between Shell and Module, loading and unloading, etc.

Essentially, I'm thinking of developing the Shell as a State Machine to load modules based on it's state, etc.

Thanks!
sd

Hello,

Managing popups, the saga:  I've sifted through the few posts on managing popups in an application and in a pureMVC application.  I am currently refactoring a popup system for reuse-ability, and I want to open the discussion for feedback.  We're using AS3 (no Flex Framework) with pureMVC multicore...

THE BACKGROUND: THE PROBLEM
I started with a PopupMediator as an API to create/show popups within the application.  The PopupMediator's View was actually not the popupView itself, but a top-level view container into which popupViews would be shuttled onto and off of the stage, so that they were always at a z-level above other views in the application.

At first there was only a few popups, a common popupView and a few specialized popups, each extending an AbstractPopupView.  Because transitioning popups visually onto and off of the stage was the same for all popups, the AbstractPopupView defind methods for this feature, as well as an activate/deactivate API for sub-components that could be overridden by specialized, concrete popups.  This worked very well until the application grew, and need for more specialized popups arose, and you can well imagine that the PopupMediator bloated well beyond its original intention, with an API to show each needed popup as well as handlers for each popupView's interaction.  Maintenance is a drag!

THE FOREGROUND: THE SOLUTION
So, to refactoring a system:

I'm thinking that I am going to encapsulate ALL requests for a concrete popupView into a single command PER concrete popupView.  I can generally break the requests to be handled for a popup into 3 types:

1. CREATE_POPUP: The creation of the popupView and populating it with the appropriate data, and any actor can send a notification to fire this
2. HANDLE_POPUP: The handling of user interaction with the poupView, generally, this will be responses to MouseEvents.
3. DESTROY_POPUP: The deactivation, removal and destruction of the popupView.

So for each concrete popupView, I will have a HandleMyConcretePopupCommand extending a AbstractHandlePopupCommand.  And using the Template Method to call the appropriate method, based on the TYPE param of the pureMVC notification, I will handle the request appropriately WITHIN THE SAME COMMAND.

So for Creation, because we're dealing with concrete Commands, we don't really need to accept a 'createPopupVO', with pairing popupView Class and Mediator; the popupView can be instantiated directly herein.  However, if the popupView requires specific view-data, we can pass it in the note body and pass along to the Command's create method, where it will be typed and thus expected.  The popupView will be passed to the PopupMediator, the PopupMediator will listen for MouseEvents.

As MouseEvents generated by the poupView are handled by the PopupMediator, the PopupMediator will in turn send a notification paired to the same HandleMyConcretePopupCommand, but in this case, I will accept the MouseEvent in the notification, and call the handlePopup method in the Command, which will give us the popupView as the target or currentTarget.

For Destruction, I will kill anything that needs killing, and remove the popupView from the displayList, and destroy the popupView.

Given that Command objects in pureMVC are created and destroyed on usage, the handling of all three types of popup requests, creation, mouse handling, and destruction, can be neatly collected in one Command object.  I just need to be sure that Commands are in fact destroyed after usage, and not kept floating around - this might throw a wrench into the cogs.  Can someone advise specifically here?

I know that I could (and by suggested best practice, SHOULD), create a Mediator per popupView that merits complex interaction.  But given that the Mediator in pureMVC is only suppose to act on behalf of the View Component when communicating with the other actors of the pureMVC system (data and controllers), I want to suggest I keep only ONE PopupMediator for the application.  This Mediator can simply listen for MouseEvents generated by the popupView, and send a note mapped to the appropriate Command.  I'll figure out a way of mapping the target of MouseEvent to the appropriate HandleMyConcretePopupCommand.  But any specific logic that needs to be handled because of user interaction can be dealt with in the HandleMyConcretePopupCommand handlePopup method, and not directly in the View or the PopupMediator.  The only time this becomes 'iffy' is in the case where handling the popup might require adding and handling a contextual listener to the popup; still, this could be handled in the same manner, by routing it through the one PopupMediator, which will fire the appropriate HandleMyConcretePopupCommand, which will handle the context.  It's just when I think about it: one concrete Mediator to one concrete popupView? Too much work...

To me, this seems clean: all Controller like code per popupView is collected into one Command per popupView.  This will make management much easier, I think.

Adding, removing, and z-level of the popView could either be handled by the one PopupMediator, or, by a PopupManager Singleton not related to pureMVC.

Anyway, that's what I'm thinking...someone stop me if I'm crazy!  I'm happy to share the implementation, and will do so as I develop it, but I would be grateful for comments as I'm planning the building of this spaceship...

OR, ahh, what about the Factory Method in this system...perhaps the creation of concrete popups should be handled by parallel creation Objects, hmm...so many routes here...

Thanks, sd

I was wondering what you thought of this post about organizing notifications:

http://labs.almerblank.com/2009/11/organizing-puremvc-notifications/

I like the idea of a Notifications Class, typed to INotifications that implements:

function register():void;
function remove():void;

But the last suggestion in this post is also interesting, by aggregating notifications specific to areas of an application in an all encompassing Notifications Class, which could be accessed through the facade.  However, I'm not certain about breaking from the best practice of using public static constants in the concrete Notification Class (LoginNotifications) and instead using only public constants.

Please see the above post...

Could you advise on best practice here?  Thanks!

Ok, I've been asking questions, and I've been getting great answers, thanks so much for your time, Mr. Cliff!

Here's one about Proxies: In the case of using a Proxy to load XML, given that AS3 has pretty powerful XML capabilities with E4X, I often like to keep incoming XML data within an XML or XMLList object.  However, in PureMVC, because Proxies are suppose to steward a data object or VO, usually I see people shuttling their XML data into the VO.  But sometimes I'd kind of rather not do this...but instead just hold the loaded XML in an E4X friendly object.  Does that mean I can't be in the PureMVC club anymore?

But seriously, given that the Proxy is expecting a VO or data object, how should I proceed here?

Could I just do this within the constructor of the concrete Proxy:

:

public function MyProxy()
{
super(NAME, new XML());

// other concrete stuff
}

...and something like this in the onComplete handler of the URLLoader (PLEASE NOTE: the implicit getter for xml, which cast the inherited member, data, as an XML object ):

:

private function onComplete(e:Event):void
{
xml = new XML(e.target.data);
xml.ignoreWhitespace = true;
sendNotification(LOAD_COMPLETE, xml)
}

public function get xml():XML
{
return data as XML;
}

Would this be cool for handling XML?

Thanks!

I've been studying hard on best practices, run through tutorials, searched and read posts, and there's still some general Multicore structural stuff not clear to me, so please forgive me if I ask a pile of basic questions here, many of which maybe well known to the community.

1. Cores: Shell (or other common names like Application, Main, Index) vs Modules?  Is the Shell's primary deal to load modules?  If so, where does this happen?  The 'getting started' tutorials I've read show the modules being created in a variety of Classes: in the Shell's Document Class, another in the ShellMediator - what is best practice here?  Does it matter where they are loaded?  Is there a utility for managing this?

2. Using/loading actual Modules:  Again, most of the getting started tutorials house the Shell and all Modules in sub-packages of the same application, ie: src.com.myapp.shell, src.com.myapp.moduleA, etc, but is this actually modular beyond packaging? 

In building non-Flex AS3 applications, I prefer to create modular sections of the application that can run on their own, this way I don't have to compile and wade through an entire application to test each Module.  I'm sure this is standard for most developers, however, in PureMVC, how would this handled exactly?  Should I load into the Shell (when I find out where it is best to do so) an swf file (a Module) typed to an Interface?


I'm sure I'll have many more questions, thanks very much!