Usually, a Proxy is pretty light and there usually aren't that many of them to register for a given app. I find that just registering them all to begin with (but not telling them to automatically fetch data) is a good way to ensure they're present and accounted for whenever needed. I don't see that delaying their instantiation until the mediator that needs them is registered has a lot of value.

But if you have a situation where it does make sense, then the above seems like it would work to me.

Well, essentially, the situation is that my project manager is telling me to do it that way.  I can also see where he is coming from (ie: why would you instantiate a Proxy before it's needed?).  Until I read your response I had just been deferring to his wisdom (he's been on this project from the very start, unlike me).  I can reason with him, though.

Next, our application has a TON of proxies... at least 50 classes... perhaps up to 100 instantiated.  The amount and types of data retrieved from servers is also immense.  On a side note, I have been trying to figure out a way to modularize the application into MultiCore without success... then, in theory, I could have like a dozen core apps with just a few proxies each.  But for now, it is not the case.  Honestly, simplifying our model tier feels like fighting the Hydra with a butter knife, and with the same predictable results.

The only other reason I can come up with is that most of our proxies grab server data automatically upon onRegister().  But I suspect you would say that I should simply move that logic from onRegister() into a different method (call it retrieveData()) which is called when the proxy's data actually needs to be retrieved.  As it is, there are some situations where I have to do that anyway (eg polling).  But where would I call such a method?  From inside the Mediators that use those proxies?  If I try to do it from inside the RegisterMediatorForComponentCommand then I am back to square 1 (ie how do I know which proxies need their retrieveData() method called?).

Thanks for the response.  Sorry if I am straying a bit off topic!

Adrian's idea is cool because it actually cuts down on the number of classes needed.  In this case Command classes.  The only drawback I can see immediately is if, like me, you combine the model initialization with the view initialization in the same command.  That makes it a bit harder to simplify.

Probably for Adrian, his application development follows a different pattern.  One thing I don't like about notifications is that it is hard to keep track what to expect in the body.  I have to get people to write code comments describing what each notification that comes into handleNotification() or execute() has in its body and some people are less diligent than others.  His use of the VO here is very appealing.  It never occurred to me to extend VO usage beyond Proxy notifications... thanks Adrian!

Cliff and Adrian, what would you think if RegisterMediatorVO class had an additional parameter for an array of Proxy classes to create and register in RegisterMediatorForComponentCommand?

:

override public function execute(notification:INotification):void {
  var registerMediatorVO:RegisterMediatorVO = notification.getBody() as RegisterMediatorVO;
  for each (var proxyClass:Class in registerMediatorVO.proxies) {
    if (!facade.hasProxy(proxyClass.NAME)) {
      facade.registerProxy(new proxyClass());
    }
  }
 
  ... continue registering mediator, etc.

Something like this would probably cover most of my cases.  (note: my proxies get their data from servers, but if they need to be instantiated with data, could that not also be included in the VO?  is this too complex?)

Thank you.

I am creating VO's like crazy now and feeling good about it!

Best,
Sammi

It's a wonderful feeling.

I have a similar situation.  In some cases I have "sub" VO's for items deeper in the hierarchy that are still complex and frequently used.  Other times I just return the xml node and work directly with it.  In my case, if around >n classes use the same piece of data then I make a sub-VO for it and have the smart VO wrap the xml node in it when it returns the data from some getter.  In my case, n = 4.

I don't think there is anything to worry about.  Do what makes sense.  Smart VO is not a PureMVC specific concept.

If your application is complex, it will have a lot of VO's.  Still better that than editing XML references all over the place, right?

The MacroCommand does not execute logic, rather it calls the execute() method of the SimpleCommands that it.. uh.. macros (is that a verb???).  Any "extra" logic should be in an extra SimpleCommand that the MacroCommand also executes.  In your case, the second code-block is exactly correct.

Anyway, MacroCommand and SimpleCommand are very different things.  The SimpleCommand does stuff (like an .exe) while the MacroCommand just bundles a bunch of SimpleCommands so they do their thing all at once and with one notification (like a .bat).  Or, more apropos, an Excel macro does not do anything in addition to the simple commands that it contains.  Whether I do it by hand or with a macro, the process in Excel is identical.  I believe that's the definition of a macro.  So if the MacroCommand's execute() does anything else, it's not really a macro anymore but some weird hybrid thing-that-should-not-be.  Thus the reasoning, I assume, behind execute being final.

An alternative is that you could make a "boss" SimpleCommand that sends the notifications required to execute all those other commands and perform some additional logic within its execute.  The notification name would not be shared among the commands the way it is with MacroCommand but ideally SimpleCommands shouldn't care what the name of their notification is anyway and the overall functionality would be identical.  I'm just not sure if it is good etiquette to execute SimpleCommands from within other SimpleCommands.

1. In the "Best practices" document, it says that we should use the ApplicationFacade class to declare all the constants for the notifications names, or use an external class, but i've seen that the notifications names that are going to be send by the proxies are defined within themselves(the proxies), so, should we declare the names on ApplicationFacade/External classes, proxies or a mixture between both?

Yeah, I had the same issue you did.  All I can say is that, for me, the natural progression from the best practices document to real life application is to start declaring your Proxy notifications on the Proxies themselves.  It is just more convenient, especially to keep the model tier portable.  There are drawbacks to this approach as well (versus using, say, a common ApplicationConstants class), but in some real world situations, it is just naturally easier for the Proxies to contain their own notification constants than to try to organize them in a common location.  I believe that is why many people (including myself) do it that way.  These are not the only two options, by the way (just the two easiest!).

The short answer is: do it the way that feels best for you, whether you choose A, B, or X(!).  The deciding factors are often how many proxies you have, how many notifications they send, and when do they send them.

2. I'm working on a video game, and i have some data, like score, shipSpeed, lives, etc. I have a VO called GameDataVO, that holds this data and provides public setters and getters for maniputing it. I did a proxy that provides the same setters and getters, and i want to send notifications from the proxy whenever the data changes. Now, my question is, should i send a diferent notification for each property changed? i mean, something like SCORE_CHANGED, LIVES_CHANGED, SHIP_SPEED_CHANGED and pass as the body each piece of data? or should i send a general notification GAME_DATA_CHANGED, a VO with the data as a body, and use the type property to specify the type of data changed? or there is another better way?

It sounds to me like the second option, one notification with different types, is preferable.  But I would like to first check whether this is a question between having 5 different notifications vs 5 of the same notification with different types--all being fired simultaneously.  Because if that is the case, then I would look for a way to bundle all the changes so there is less processing.  But if, as I assume, it's just that one property or the other occasionally changes and it's a question of whether to have 5 different notification names vs one notification name with a variable type, I would, like I said, go for the second option.  Just seems more logical.

Thanks again Cliff for the reply.  I know this is all basic MVC theory stuff but I have never used MVC (outside of one tutorial) until PureMVC.  I appreciate the crash-course education you provide!

Huh.  That is an interesting idea.  I had totally forgotten about LocalConnection.  I've always found it clunky.  But you are probably right, having two independent AIR applications that communicate with one another (one app being the master, the other the slave) might work on separate processors depending on the computer and the OS.  The master or shell could establish the other cores via the local connection I guess???  Is that what you are thinking?  It seems like a major pain, though! 

Maybe someone will come along and make a LocalConnection Multi-thread utility for PureMVC???

Thanks!  I felt very comfortable explaining the coupling issues with Mediators, but less so regarding Proxies.  Furthermore, if I follow you correctly, when a Command calls a method on the proxy, that makes the Command dependent on the Proxy but not vice-versa.  Keeping the model tier portable at the expense of the control tier's independence.  I think I finally got it.

I'm going to go out on a limb here and say no.

First of all, Multicore is just a framework.  It does not affect the guts of the flash player, which leads to

Second, flash player cannot multi-thread (http://cookbooks.adobe.com/post_Is_multi_threading_possible_in_Flash_or_ActionScri-12026.html).  There are certain tricks you can do using the enter frame event, however, that may achieve the desired result.  But Multicore does not in and of itself contain any code for formalizing that process.  It's pretty rare to do so by the way.  In our huge spaghetti project, I use the enter frame trick only once to avoid a script timeout.  And meanwhile the dual CPU is chugging along at 50%.

PS
here's someone lamenting the lack of multi-threading in AIR: http://www.flexjunk.com/2009/01/15/multi-threading-in-flexair/

Ok, I am anticipating this question coming up in my project:

Why is it ok for a Command to grab a Proxy and call some method directly on that Proxy but the same thing is not allowed for a Mediator?

Ideally, Proxies do their own work, but sometimes I need to control them via a Command (for example, tell a Proxy that it no longer need retrieve data from the server in real-time; tell a Proxy to refresh its data from the server; etc.--it's always for remote data).  From what I have seen so far, it is ok for a Command to grab a Proxy and call some method implemented on that Proxy to accomplish any one of those things.  Correct me if I am wrong, please.

But for a Mediator, it is incorrect to grab its instance and tell it to do something.  Use a notification instead.

Obviously, since Proxies can't respond to Notifications there is no choice but to call a method on the Proxy instance.  But now it begs the question, so why not Mediators, too?  What's good for the goose is good for the gander, right?

Anyway, I think I am missing something here, and since I am going to have to explain this to my co-workers soon, I don't want to sputter when they make this argument.  Or even worse, I don't want to make a mistaken argument.

So again, please, tell me why it is ok for a Command to call methods directly on a Proxy but be forced to do the same via a Notification for a Mediator.  And if my question contains a false assumption, please tell me that, too.

Thanks!

1) ControlPanelMediator sends a TOGGLE_SIDEBAR_COMMAND notification, which solely causes execution of the ToggleSidebarCommand. This command retrieves the SidebarMediator from the façade, and calls its toggleVisibility() method directly. That method toggles the actual sidebar Sprite's visibilty.
2) ControlPanelMediator sends a SIDEBAR_TOGGLE_BUTTON_CLICKED notification. The SidebarMediator is listening for this Notification, and toggles the sidebar Sprite's visibility in response to this.
Any thoughts, or links, anyone? (Sorry if this post is a bit jumbled!)

Number 1 feels natural, and I have done it myself, but it is not correct.
Number 2 is better.
Your mediators should not expose public methods to be called directly by commands or other mediators.  Rather, they should react to notifications.  If you modify 1 to do this then you would end up with a command that dispatches a notification to a Mediator, needlessly increasing the number of notifications.  So I recommend 2 because it cuts out the Command middle-man.  If you have more complicated business logic involved (such as re-querying proxies, etc.) then the modified 1 option (ie using a Command to modify visibility via notification) makes sense.

edit:
here's the relevant link
http://forums.puremvc.org/index.php?topic=1698.msg7703#msg7703

Right, I fully comprehend all too well what you are saying.  People on my project have already gone slaloming down that slope (myself included), bloating Mediators with code to the point that the difference between the Mediators and their views is often arbitrary.  So, allow me to just apply your advice concretely to the above example:

Rather than have the ShowEmployeePopUpCommand directly set the employee id (contained in its notification) via a public method on the EmployeePopUpMediator instance that it registers, it should dispatch a new notification (call it "SetEmployeeId") which the EmployeePopUpMediator would then respond to.

I would still get the show-and-set-state functionality out of one Command, but the two tasks would be articulated with separate Notifications and the Mediator would no longer have/require a public method for setting a state.

This seemed a bit verbose to me but... well, slippery slope.  It would be nice if the Mediator and the Command could respond to the same notification, but since the command actually registers the Mediator (if it's not registered already, ie the first time), I don't think this is possible.

Anyway, thanks and please correct me (yet again) if I am wrong.

1. I am keen to pass arguments directly from commands to mediators through exposed public methods, but am under the impression that I should always use notifications to do this?

Sometimes this is needed if a command is doing a lot of complex logic that involves two-way communications with various Mediators. In this case, you often need to expose methods on the Mediators and invoke them from Commands. This happens, but it is rare.

99% of Commands don't need to do this, and by sending notes instead of retrieving the Mediator and invoking a method on it, you are more loosely-coupled, and in OOP, this is generally considered a good thing.

I have a question.  What if the command is used to register the mediator and its proxies?  Wouldn't directly setting some basic/common properties on the Mediator actually make a lot of sense (ie apply to more than 1% of Commands)? 

I have an app which opens a pop-up via a command notification when the user clicks the screen.  Depending on where the user clicks, the initial state of the pop-up is different (imagine different buttons for different employees where the pop-up is the same, but the employee information to display depends upon the button pressed).  So I send a SHOW_EMPLOYEE_POPUP notification which has the employee id.  I use a ShowEmployeePopup command to register the Mediator and Proxies necessary to initialize the popup (on subsequent calls, this is not necessary and is skipped).  Once the view is set-up, in the same command, I then just set the employee id on a public property of the Mediator which then does some other things as necessary (like grabbing the employee's info from various proxies).

So, ShowEmployeePopUp sets up the view the first time it is called.  Then it immediately sets the employee id (located in its notification) to the EmployeePopUpMediator (and tells it to become visible).  I found this convenient because it allowed me to contain the relatively simple initialization and "show" logic in one command instead of two (and also centralize the check-if-instantiated logic).  Finally, since this command has to register the EmployeePopUpMediator, why not just keep it simple and directly access its properties?  Why would I send a notification to set a property on a Mediator which I already have a reference for? -- that's my thinking anyway.

So did I just happen to fall in that 1% sweet spot?  Or am I doing something wrong?

Thanks for the advice Cliff.
I'll follow it.
I'll try taking #1 tack with my supervisor.   During my downtime, I will continue to try to come up with a MultiCore app that uses interfaces to handle the modules as a proof-of-concept type thing to show him later.

Because of the way the application is currently put together and the structure of the data that is used, I know I am going to have to have communication between the shell and the modules.  Pipes is far more complex than I want to get involved with right now, especially for the task at hand.  I did take a look at LICS a while back and it is closer to what I would come up with naturally on my own but there were some things I didn't like as well (can't recall what).  Anyway, I think I can get what I want with a few interfaces and then if more complexity creeps in later, we can re-evaluate pipes and LICS.

PS

Btw, what do you think of this idea:
Most of our Mediators instantiate their own view component upon registration.  What if instead they first loaded a module and then instantiated their view component from the module (upon registration)?  Of course, this still requires the Mediator to access its view component through an interface or it's meaningless.