Frustrating problem about what to do with data modified in a viewComponent

[jpwrunyan]

I have a frustrating problem that I can't figure out the solution to without breaking PureMVC convention.

I have two mediators for two separate views in the application.
One mediator is for a viewComponent that manipulates some data that eventually becomes the parameters of a server request.  This data is made from scratch.  It originates in the viewComponent based on user interaction.

The other mediator is for a viewComponent that serves as a control panel for, among other things, triggering the above mentioned server request (via a "ServerRequestCommand" notification).

My problem is, I cannot think of a way to grab the necessary parameters through the parameter-setting viewComponent without just directly calling a get method on its mediator.

But isn't this anti-pattern?

:

ServerRequestCommand extends SimpleCommand {
  public function execute(notification:INotification):void {
    var params:Array = ParamSettingViewCompMed(
      facade.retriveMediator("ParamSettingViewCompMed")
    ).getParams();
    //business logic follows...
  }
}

Even if I pass the parameters in the body of the command's notification (which seems correct), that just means the problem is moved from the command class to the control panel mediator class that sends the notification.

:

ControlPanelMediator extends Mediator {
  ...
  public function serverRequestButtonClickHandler(event:MouseEvent):void {
    var params:Array = ParamSettingViewCompMed(
      facade.retriveMediator("ParamSettingViewCompMed")
    ).getParams();
    sendNotification("ServerRequestCommand", params);
  }
}

Is my whole architecture screwed up?  I'd really like to get this right before implementing similar stuff down the road.

My general rule of thumb so far has been that only Proxy classes may have methods that are directly called by other actors (ie Commands and Mediators)--everything else goes through Notifications.

[puremvc]

1) Control Panel 'Go' button clicked.
2) ControlPanel raises GO event
3) ControlPanelMediator handles GO event by sending GO notification
4) ParamSettingsMediator handles GO notification by sending SERVER_REQUEST notification, with ParamSettingsView.params as body of note
5) ServerRequestCommand is triggered by SERVER_REQUEST note
6) ServerRequestCommand finds the params in the body of the note, massages or validates them, and ultimately invokes request method on a Proxy, which makes the server call.

QED

Cheers,
-=Cliff>

[jpwrunyan]

Cliff, thanks.

I think where I got lost was that actually this param-setting Mediator can have multiple instances.  But each instance, though the param-setting view classes may be the same, will end up having to send a different server request in response to a control panel notification (each view sets params for different data services).  Unfortunately, for simplicity's sake, I think I want each request to be handled by a unique Command/Proxy... which means it looks like I will have to ditch the one-size-fits-all param-setting Mediator class.

I don't know, this is a philosophical question perhaps, but I guess I prefer having lots of similar one-instance classes as opposed to having one catch-all class whose instantiation process is overly intricate and complicated... and susceptible to abuse down the road. 
As long as it is simple, sensible, and obvious, I would use one Mediator class with multiple instances, differentiated by mediatorName, but the above problem with what to do about unique server requests that have very different business logic (and therefore, in my opinion, require different notification names) may be the straw that breaks this camel's back.

If you think I may be giving up too easily, let me know.

Alternatively, what is your reaction to the idea of a single catch-all server request command that switches off its notification type and then handles a variety of business logic from there?  (my gut reaction is revulsion... but I'd like your opinion)  If I allow myself to do that, I could see possibly going back into the forest and coming out the other side.

[puremvc]

I agree the mega command idea is hideous.

OK, you've got one GO button, but multiple settings panels, each of which could be collecting info for a different server request. But if you click GO do you want all of them to send requests, or is it that the 'selected' one that you're entering params into at the moment needs feed a single request?

If the latter is the case, then I imagine that the one instance of ParamsSettingsMediator whose child has the focus would be the only one to respond to the GO notification. Based on what type of ParamsSettingsView it happens to be mediating, it sends off one of X different SERVER_REQUEST_X notifications, each of which is mapped to its own command for processing that particular kind of server request.

So this follows the same basic flow I originally put forward. You just have to be sure that only one instance of the mediator responds (although all will be notified) and that it has an easy way to see if its child is focused, what 'type' of settings panel it is (by having the view implement an interface or expose a constant),  and what the corresponding outbound notification name for the view type is.

-=Cliff>