Commands vs. Notifications

[undefinedman]

Hello Cliff, hello everyone!

I have started the adventure with PureMVC some time ago and I am fully in love with this, but there are some little things that I would like to know. My main problem is declaring Commands and Notifications. I will try to describe it as detailed as possible.

I communicate Flash app with PHP which returns JSON strings, every time I need data, I have to make a call to api.

UserMediator is a screen which makes a request to api via UserCommand:

:

facade.registerCommand(UserCommand.GET_USER, UserCommand)
[...]
sendNotification(UserCommand.GET_USER, [UserColumn.EMAIL, UserColumn.NAME]);

UserCommand sends the request to UserProxy:

:

switch(notification.getName())
{
     case GET_USER:
          userProxy.getUser(notification.getBody() as Array);
          break;
}

UserProxy sends the request forward to ApiProxy:

:

public function getUser($data:Array):void
{
      apiProxy.sendApiRequest(RequestType.USER, RequestMethod.GET, RequestAction.CURRENT, $data);
}

When ApiProxy will finish loading the data it will fire onComplete event and now data is available.. but I have problems to send it, because I can say:

:

sendNotification(UserNotification.COMPLETE, $event.target.data);

and receive it in the Mediator, but what if I will ask for more data, e.g.

:

sendNotification(UserCommand.GET_USER, [UserColumn.EMAIL, UserColumn.NAME]); //will give me email address and the name of the current users
sendNotification(UserCommand.GET_ALL_USERS, [UserColumn.ID, UserColumn.NAME]); //will give me id and the name of all users in db

and it will go to ApiProxy where it will send the same notification which is not good OR specify for each command own notification, e.g.

:

UserCommand.GET_USER -> UserNotification.USER_COMPLETE
UserCommand.GET_ALL_USERS -> UserNotification.ALL_USERS_COMPLETE

I have many things to request from api and those solutions makes my app complicated to develop..
I would like to know the best way to solve those kinds of commands/notifications..

[puremvc]

What you need is an implementation of the Asynchronous Token pattern that is handily available to us in Flex as the AsyncToken class. If you are using Flash, then unless you can find an implementation of it, you'll have to roll your own.

Basically, the way it works is

1) The user follows one of a number of use cases that causes the client to invoke a service.
2) The client invokes the specified service, and the synchronous result of the call is an object called a 'token'. The token is a dynamic object you can add properties to on the fly, and the service call sets a unique id or serial number to the token before returning it to you. It also sends that id to the service.
3) After making the call and receiving the token, you set one or more properties on the token that help you remember what you were doing when you made the call (e.g., which call was made, data that was sent, etc.)
4) The service sends a response to the client, including the token id.
5) The client matches the response with the appropriate token and voila, you can resume where you left off (e.g., sending the correct notification based on the call that was made.

Now in Flex the AsyncToken is returned to you, you set properties on it and don't even bother hanging onto it, because the response event will have not only the data from the server but also the token. And also your service doesn't need to accept the token as an argument and return it, it's handled 'out of band' by Flex.

But if you're rolling your own, you may have to add a token id to your api and return it in your response. And hang onto the token in an Array or Vector in the ApiProxy. On getting the response, get the token id, splice it out of the Array or Vector, and use it. I'd say have the UserProxy pass in the notification name that it like to have sent when the response comes back. That way, when the ApiProxy makes the call, it sets that note on the token that it stuffs in the Vector and then when it gets the response, the token is telling it what note to send on success. You might want to send in an optional note for failure as well, if you have special handling for a given call, overriding a standard note that would be sent otherwise. And if you store the arguments for the call on your token then that might be useful for you when you are sending out a failure note....

Also, in your scheme you don't really need the UserCommand. You could just have the Mediator make the service call.

Hope this helps,
-=Cliff>

[undefinedman]

Thank you very much, I changed a bit the way of gathering data and now the structure is more clear. Thanks again for your help.

Best regards, Gregory.