When is it a good time to remove elements (Proxy,Mediator,Commands) from the facade? Would it be "better" to leave all the assets available rather than subscribing/unsubscribing?

IMO, a good time to remove the PureMVC actors is when navigating away or switching away from the view doesn't automatically destroy them.

Suppose, you have an application in which the functionality is implemented as modules and clicking on the NEXT or the PREVIOUS button unloads the current module and loads the next one.In this case, the only thing you need to destroy is the Facade. There are two reasons for this:

• Destroying the facade automatically does away with the registered Proxies, Mediators and Commands.
• Destruction is required since you would want a new core or a new Facade instance rather than the old one which preserves the previous application state

The only time I've felt a need to destroy mediators is when my application is structured as multiple stacked views [implemented as ViewStack in Flex] which don't get destroyed when the user switches views but merely are hidden from the user. In this case, keeping the old Mediator with it's event listeners registered with the view can have unforeseen consequences like hard-to-find bugs.

I never bother with Commands and Proxies since I almost always register them at the Facade level and since I make sure I destroy the Facade, those two are automatically taken care of.

-sasuke

Or if it is just the data you are interested in, you can retrieve the same in the mediator [assuming that both ProxyA and ProxyB are registered in the same facade] and then send the data as a notification body. This has the advantage of the Command not knowing where the data has come from. So if tomorrow, Proxy A in the command needs to use the data from ProxyC instead of ProxyB, the only change will be in the mediator. This is how the flow should be:

• User dispatches an event
• Mediator retrieves the data from ProxyB and sends a notification with the data in the body
• Command gathers that notification and retrieves the data from the body
• ProxyA uses the information *without* knowing anything about ProxyB

IMO, it's a win-win situation given that you get the data + the loose coupling.

And if ProxyB belongs to a different Facade, I'd recommend having a separate module which manages the flow of data to-n-fro along with data sharing between proxies so as to again facilitate for loose coupling.

Hi there.

> You can use a local file (SharedObject if you use Flash) to store user info

This is definitely not a choice in my case since the user can disable the SharedObject implementation by setting the size to 0kb in the Flash Player setting thereby rendering the entire application useless.

> A better but more complex solution is to implement PureMVC Pipes

Unfortunately, the application is almost complete and plugging in a new architectural piece at this moment might not be possible.

> If the application is large enough the definitive solution is to have a module dedicated to user info
> management, each module asking or receiving user infos updates

This sounds interesting; is the term "module" here used in the Pipes context or in the context of a Facade like UserInfoFacade which would be dedicated to managing user information, expiring sessions etc.? On a related note, I hope it isn't an anti-pattern to have a facade which isn't related to a concrete view per-se?

TIA,
sasuke.

Hi all,

Recently I've been developing a multi-core PureMVC web application in Flex [i.e. more than one core is active at any given time]. When the user logs in the system, I set the user credentials in a User object which is cached by the UserProxy class [which maps to the User VO]. All this action happens in the main or the parent facade, for the sake of completeness, let's call it ShellFacade.

What would be a good design choice for making this cached User VO present in the UserProxy class [which is currently registered in the ShellFacade] available to other cores [e.g. facade XXX]? One way I can think of is to:

• Retrieve the UserProxy of the ShellFacade in the XXX facade startup command
• Register the user proxy in the XXX facade using the retrieved proxy

:

class XXXStartupCommand extends SimpleCommand implements ICommand
{
   override public function execute(notification:INotification):void
   {
      var userProxy:IProxy = ShellFacade.getInstance(ShellFacade.NAME).retrieveProxy(UserProxy.NAME);
      facade.registerProxy(userProxy);
      // remaining code
   }
}
This of course creates a dependency of ShellFacade in the facade XXX command which seems a bit problematic since it hinders the reuse of this independent module in other scenarios. Is there any other way of doing this? Any design pattern which I can apply to reduce the coupling which would get introduced here?

I perfectly understand that it wouldn't be a big thing to change the ShellFacade to something else in case I decide to use the facade XXX in some other scenario but I'd like to avoid that. Suggestions welcome.

TIA,
sasuke

I'm looking for the best (or at least a good) way to handle the following:

I need to call one HTTPService many times, and wait for all the results, and put them in order.

The reason is, I have a path of coordinates, and for each I call a service to get the elevation of that point. Once I have them all I will chart them, so they need to be in order of the path.

Thanks in advance for any thoughts.

IMO, calling a remote method for each and every *point* is way too expensive. I don't know the scale of your application but with multiple users, this might just bring the system to its knees. You might want to try imparting batch processing capabilities to your HttpService and make it accept a list of points which in turn would return a list of elevations. Just a thought...

BTW, how are you associating each unique response received with the request which initiated it? Asynctoken?

-sasuke

On a related note, I feel that this point deserves a special mention in the documentation which states:

The View primarily caches named references to Mediators. Mediator
code stewards View Components,  adding event listeners, sending
and receiving notifications to and from the rest of the system on
their behalf and directly manipulating their state. 
 
This separates the View definition from the logic that controls it.

This para might just give the users of PureMVC an impression that everything needs to go through the mediator. Just a thought...?

Because it is still perfectly valid for components to communicate with each other via events.

-=Cliff>

Cool, that gives me two reasons for not pushing all the events to the mediator. Thank you everyone for your kind contributions. :-)

The mediator is only concerned with events that require it to perform some other request. It may be to get data from a proxy and set it on the component,  or to send a notification that accomplishes some other task (via a command or some other mediator listening for it). The rest of your views should send and receive events as they normally would in any none "frameworked" app. You don't want to route everything through the mediator, only things that require some action to be performed by other PMVC actors (Proxy, Mediator and Commands).

Cool, that's what my impressions were; stuffing everything in the mediator would be kinda messy given the role which has been assigned to a mediator i.e. mediation. Thanks for confirmation.

BTW, just so that we have the technicalities cleared up, what reason do you think I should present if I'm giving a PureMVC session and someone ends up asking "Why aren't all the events directed to the mediator? What practical harm might come of it other than the normal 'it is not a job of the mediator'"?

One reason that I can think of is that, the more "view" specific code in the mediator, the more difficult it becomes to port the mediator if the view changes given the high dependence of the mediator on the view. Any other reasons you can come up with?

TIA,
sasuke

Hello everyone.

As far as my understanding goes, the mediator has the responsibility of mediating or orchestrating the components or the core actors of the PureMVC framework. So for e.g. if you would want to retrieve a piece of data from the database on your submit button, an event is dispatched from the button which is handled by the mediator which in turn:
- uses the cached proxy to make the webservice call OR
- fires off another notification which triggers or executes a command which in turn makes a webservice call

But is it logical to fire off local events to the mediator? By local events I mean events which don't need to interact with the PureMVC machinery and can complete on their own. For e.g. if on the click of a radio button I want to do some set a view property[ a variable declared in the script tag of the MXML file] to the value of the radio button, should I fire off a custom event on the click of the radio button which would then be picked up by the mediator or can I just write a handler method in the script tag which does all the processing without going to the mediator? Is is required that *all* events which the view is interested in capturing need to be dispatched to the mediator?

TIA,
sasuke

I am working on an application using PureMVC for the first time.  I have the need to print some visual data.  I have a mediator, lets call it PrintAreaMediator, that is listening for the PRINT notification which is sent from another mediator which stewards a file menu (including the print button).  Should the PrintAreaMediator kick off the printjob (passing its viewComponent as the print content) or should a command (PrintCommand) be used instead in which it would retrieve the PrintAreaMediator and ask for its' viewComponent to pass to the printjob?  Also, where would be the best place (package wise) to place the Printer class (it is a singleton that wraps a printjob).  Do many of you create a utils package as well alongside the model, view, controller?

Hi there,

I think I can come up with two ways to tackle this issue:
- You should have a parent mediator which would be listening to such 'cross-cutting concerns' and sending appropriate notifications in response i.e. since you have two view areas in your application, you would also have some sort of mediation logic or a mediator for the entire application and that mediator automagially becomes your parent mediator in this case.
- Send a notification to the facade from your Menumediator which would be turn be broadcasted to all the puremvc actors i.e. facade.sendNotification(SOME_THING). Make the PrintAreaMediator listen to this notification and your job is done. Make sure you create a command for this printing since there might be other areas in your application which might be needing the print facility.

And yes, I do end up creating util packages for things which have no bearing whatsoever on the MVC way of things. Though creating or using a Proxy pattern to handle this printing job would be a good PureMVC exercise.... :-)

> Something such as a CustomTextField class should not have a mediator associated with it.

I'm with you on this one; that would be going too far IMO. Mediators should be used when a view needs to offload it's mediation logic to an entity since placing all the event handling code in the view itself or in a separate ad-hoc script file would be too limiting.

> Mediators are only when a view component needs to communicate with the rest of the application in
> which case a Mediator should mediate those needs with the rest of the application via notifications.
> Otherwise a regular component class should suffice

Again agreed; async communication using notifications is the way to go and is much more preferred over having global stores in your application to share data between components. The way I work with PureMVC is to delegate all the PureMVC event handling stuff to the mediator and in case there needs to be performed some screen specific logic, again delegate the control back to the view.

:

public class MyMediator extends Mediator {
  // Constructor

  public function get module():MyView {
    return viewComponent as MyView;
  }

  override public function listNotificationInterests():Array {
    return [MyFacade.DATA_RETRIEVAL_SUCCEEDED];
  }

  override public function handleNotification(notification:INotification):void {
    switch(notification.getName()) {
      case MyFacade.DATA_RETRIEVAL_SUCCEEDED:
        var vo:MyVO = notification.getBody() as MyVO;
        module.processDataAndManipulateView(vo);
        break;
    }
  }
}

<mx:Application>
  <mx:Script>
  <![CDATA[
     public function processDataAndManipulateView(vo:MyVO) {
     // Perform view specific logic with returned data
     }
  ]]>
  </mx:Script>
  <!-- your view components/controls go here -->
</mx:Application>


Hi
Could someone describe examples of when it would make sense to use Multicore over single core?

IMO, it really depends on the application in consideration and the kind of granularity you are seeking. For e.g. you can even have a separate core for a single view like a popup search screen in an application to keep the coupling between the search and other application screens to a minimum. Or you can even have a single facade for multiple screens which are toggled using a view-stack. In this case, the views present in the viewstack form a single functionality for your application like registration. I believe there is a sample PureMVC application to this effect on the demo page.

HTH,
-sasuke

is it a wrong thing or a bad practice to remove a mediator or de-register it from within itself?

Nope. In fact that's the easiest way to deal with the mediators of transient view objects. Have the mediator listen to the view object for an event sent when it is removed. In the handler for that event just have the mediator remove itself. Also, there (or in the mediator's onRemove method), null the mediator's reference to the view component for good measure with a setViewComponent(null).

-=Cliff>

Hi Cliff,

Thanks for the response. I was kinda hesitant in doing since it seemed so much like suicide. :-)

Anyways, regarding de-registration of PureMVC actors, is it really necessary to de-register proxies, mediators, commands when removing a core? Or does removing the core do all this automagically?

Are there any anti-patterns in general regarding the removal or de-registration of core actors? Something like "would it be wrong if the facade was removed when the control is in the mediator" or "Never de-register any actor from a Proxy" etc.?

TIA,
sasuke

Hi all, a puremvc beginner here.

A really quick question; is it a wrong thing or a bad practice to remove a mediator or de-register it from within itself?

The big picture: In my application, all my views implement a common interface 'IViewComponent' which has a cleanup method. As soon as the view needs to be swapped out, the parent mediator invokes the cleanup method on the view, which in turn sends an event to the mediator which in turn does all the cleanup [typically this involves clearing the form fields, grounding all VOs, re-setting page state and finally unregistering the mediator].

I could have avoided this by:
- removing the mediator in the parent mediator itself
- retrieved the reference to the facade in the view [Facade.get...] and then removed the mediator
- fired off a command to do the removal; but this kinda makes the the 'resetting the page state' part difficult to handle [clearing the view from the command doesn't seem like a good idea]

Any suggestions or thoughts would be really appreciated.

-sasuke