Cliff,

I completely understand, thanks for the volley and your time in explication!

Much appreciated!

sd.

Hi Cliff,

I guess you're not buying my sale:

For encapsulation and decoupling, any object capable of dispatching an event should be able to do so without worry of executing a linear, singular response.  Any object capable of listening should be able to register and un-register an event-handler for the event of interest.

Does this make a program easier to follow? Yes, sure, if the role of the objects are clear.  But why use object-architecture if you want to script the flow of an application in one place?  And how scalable can that be? 

This is why generally, commands are generally registered once at the beginning of the application.

I think if you're really worried about seeing what can happen in an application at a given state, print a list of registered commands to the console...(I know, I know...blasphemy, but is Ctrl-clicking your way through function-calls in Eclipse a better way of following the flow of the Controller?)...One beauty of the Controller tier of MVC is simply that your events and responses can be visible at runtime BEFORE the events are fired.

Registering your commands at start-up doesn't make the application flow any more clear - simply because for one, events happen whenever, not in a linear fashion, and two, as mentioned, anyone can at anytime unwittingly un-register a command at any time - spaghetti code or not... Furthermore, flow charts and UML go along way toward helping the clarity of application and its flow, but reasonably speaking, design and implementation often part ways early and rarely meet again, and your employer would much rather you get on to the next project then update outdated diagrams...

I understand why it is in MVC that the Model should not be an observer but always the subject, but currently, the Controller tier of PureMVC is simply scripting a linear flow, spread across objects.  What if you want to respond to an event in two completely unrelated ways?  What if you want to sometimes respond to an event in one way, but also ALWAYS respond to the same event in another way?  In both these cases, the use of Macro Commands doesn't fly - the handlers are unrelated and the order doesn't matter.  And, if you were to use Macro Commands to do something like this, you'd have to register one Macro Command to the notification at some point in your application, and then register another different Macro Command to the same notification at another point in your application, perhaps deep in the life cycle of your application, which you're advising against...

...'somewhere deep in the life-cycle of an application' is not the place to be registering commands. It indicates you already have a spaghetti-code project.

Again, my point was actually that with the current implementation it IS possible for anyone to at any time register, overwrite and un-register a command from a notification, and given this lack of safety, it would make things more clear and safe to have to explicitly un-map a command from a notification using the notification/command pair.


Let me try you another way:

What would be wrong with implementing the registering, executing, and un-registering commands to notifications as illustrated above [un-mapping not shown]?  Wouldn't that be more flexible?  How would that kill the Pureness of PureMVC?

Thanks man!
sd.

Cliff,

Thanks for the response.  Unfortunately, to me the one to one (note to command) mapping is a bit of a design flaw...

The simple fact that a developer can join my team and unwittingly overwrite a notification to command mapping by registering a command somewhere deep in the life-cycle of an application, and thereby change expected behavior or introduce hard to track bugs, is seriously problematic.

I understand that the Controller is receiving notifications as an observer, but the controller's map of notifications does not necessarily need to remain one to one, and certainly the un-mapping doesn't need to be done simply registering a new note-to-command or by passing the note name only to the removeCommand() method.

I'm still not understanding why you'd opt for this restriction.  Multiple actors should be able to respond to an Event/Notification, IMHO, and in this case, multiple commands mapped to one note is a much more powerful and flexible solution.  Safer would be to unmapped a command explicitly with the notification/commandClass pairing, to prevent new-guy from overwriting stuff by accident.

It wouldn't be hard for a refactor on this one, in fact, I'd vote to upgrade the notification to command mapping using a simple dictionary like so:

:

// inside the Controller //
private var _mapNotesToCommands:Dictionary = new Dictionary();

public function registerCommand(note:String, commandClass:Class):void
{
if (_mapNotesToCommands[note])
{
var commands:Vector.<Class> = _mapNotesToCommands[note] as Vector.<Class>;
if (commands.indexOf(commandClass) == -1) //prevent the same command being registered twice for the same note //
commands.push(commandClass);
} else {
_mapNotesToCommands[note] = Vector.<Class>([commandClass]);
}
}

public function executeCommand( note : INotification ) : void
{
var commands:Vector.<Class> = _mapNotesToCommands[note.getName()] as Vector.<Class>;
if (commands)
{
for (var i:int = 0; i < commands.length; i++)
{
var commandClass:Class = commands[i];
if ( commandClass == null )
continue; // perhaps give the option of loggin here //

var commandInstance:ICommand = new commandClass()  as ICommand;
commandInstance.initializeNotifier( multitonKey );
commandInstance.execute( note );
}
} else {
// perhaps give the option of loggin here //
}
}

Commands could be given execution priority (like Event Listeners in AS3), and other privileges, like permanent mappings, timeouts, or mappings based on states, er whatever...just thinking out loud here...

As well, I'd prefer to see an Enum-type Object used instead of Strings to represent notifications, more powerful with strict equality as well as giving the notification a 3rd dimension, in the Object Oriented sense...but...you know...Strings are good too.

Anyway, thanks.

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

@jpwrunyan

Man, many thanks for the reply...in fact, the part where you mentioned banging your head against the desk was most helpful and brought into focus the issue: I'm trying to refactor-in the consideration of too many exceptions!  The beast we're using to manage our popups in our application out-grew its pen...and part of the problem is that we're just using the PureMVC framework incorrectly on this project in particular....so, there's a lot of tight coupling going on, but my hands are tied on that one...and so our mediators are becoming massive controllers...and a headache to manage.

My deal overall is that I'm not too keen on creating a Mediator per PopupVew, and would prefer to have a Manager handle the bulk of queuing popupViews to be rendered and removed, and specific controllers for popups, if needed, to handle their specialized mouse-events.

A black-box type seal I guess is what I'm after for a PopupManager, so it can be used anywhere.  So I'll develop my PopupManager with this in mind.  I'll post my work for any interested parties as I go.

Regardless, I totally understand your approach to shuttling views into the application via PureMVC, and use a similar system myself (sending a notification that a view was created along with the view-component, allow mediators to listen for this note, if the view should be managed by the mediator, it will be added therein, etc, something like that...).

Thanks again, more soon,
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

The answer is that you combine view states with application states.

This is decent advice for application structure, I find...

Any View complex enough to warrant using the State Pattern should dispatch its own Events based on your needs (StateEvent.TRANSITION_STARTED, StateEvent.TRANSITION_COMPLETE, etc).  This View's State should be accessible and known to any interested Controllers, which is why a public API is defined on the State Machine.  If you're plugging this View into the pureMVC framework, the Mediator stewarding the View could dispatch related pureMVC notifications for any interested pureMVC actors, as needed, as well as broadcast the View's current state to any actor that inquires.

A central State Machine for your overall application is great organization also, but regionally, complex objects should manage their own States.

Just to be clear, in the State Pattern, the term State Machine is given to the object that owns the States, and as so "defines the interface of interest to clients".  So in the case of a View that has States, the View itself IS a State Machine.

Oh, cool, now I see...

Again, thanks for your time...

Do you agree, though?  Although I initially liked Adrian's approach, and I don't mean to be negatively critical, isn't the process outlined simply wrapping the facade.registerMediator() method in a few unnecessary Classes?

sd

Writing the entire app as one class might ultimately seem simple

Huh?

I'm not sure I made myself clear...

Somewhere in the middle of Adrian's RegisterMediatorForComponentCommand Class, he has:

:

var mediator:IMediator = new MediatorClass(viewComponent) as IMediator;
if(mediator)
{
facade.registerMediator(mediator);
}
and to fire the RegisterMediatorForComponentCommand, he has to create a RegisterMediatorVO, pass in a mediator/view pair, then send a notification.

:

var registerMediatorVO:RegisterMediatorVO = new RegisterMediatorVO(LoginFormMediator, loginForm);
sendNotification(AppNotifications.REGISTER_MEDIATOR_FOR_COMPONENT, registerMediatorVO);
My point was:  From within ANY command you can just call this:

:

facade.registerMediator(new LoginFormMediator(loginForm);
..which, effectively, is what happens within his RegisterMediatorForComponentCommand.

Considering that to use the RegisterMediatorForComponentCommand you must ALREADY know the Mediator and View your want to create, why pass them through the RegisterMediatorForComponentCommand command to effectively accomplish the same thing as you would by calling facade.registerMediator() - the latter using only one line of code?  Why is the RegisterMediatorForComponentCommand approach more efficient?  I don't really see any decoupling here...just delayed instantiation.

Thanks!

Thanks, I'll try it out on my current project and report back...I see it being pretty beneficial for modules, where you can squirrel away your notifications per module...

Actually, if you have a glance at this fellow implementation, you'll notice he's suggesting using public const and a intermediary Class between the Facade and the individual notification Classes:

http://labs.almerblank.com/2009/11/organizing-puremvc-notifications/comment-page-1/#comment-13

What do you think of this?

Thanks man!

SmartVO indeed...Thanks, I get it!

Thanks for replying,

I would just like to understand the flow here because I like the steps of first retrieving your settings and then moving on:  But originally you said:

+ A PrepApplicationCommand was registered initially with the facade to listen for this [APPSETTINGS_LOADED] notification which is a macrocommand that executes a PrepModel and PrepView command.

If I understand correctly, this means that the body of the APPSETTINGS_LOADED notification is carrying the SmartVO of your settings data, and NOT a reference to your App.as [Document Class].  So, given that your PrepApplicationCommand, which is carrying the SettingsVO, is firing your PrepView command, which in turn is registering your ApplicationMediator, from where are you accessing your App.as Document Class?.

Sorry if I'm a little slow...thanks again!
sd

Thank you for posting the order of events in your application!

One question about this process however, given that your Macro Command, PrepApplicationCommand, is fired on the APPSETTINGS_LOADED notification, how do you push your Document Class to your ApplicationMediator?  It doesn't appear that the Document Class would be in the body of the  APPSETTINGS_LOADED notification...

Thanks very much!