Flex/Parsley - Use AsyncToken to return asynchronous response from Service

In Flex application, we need to manage the asynchronous responses from the service to the commands. The approach to manage this scenario is:

  • Create a AsyncToken in Service method
  • Return it to the command
  • Retain it with service for the time when we shall get the result
  • As we get the result in result handler of service, use AsyncToken to return the result to command.
  • Get the responders form the AsyncToken responders array and hand over the result or fault to these. 
  • The result or fault will be communicated to the Command result or error handler methods.
Here point is that how AsyncToken will get the responder for command. The process under the hood is that as Service return the AsyncToken to Command, and command return the same object further. Parsley framework will capture the return value, create a Responder with Command's result and fault methods and add it to the AsyncToken. So when we are accessing the first responder from AsyncToken, this is the same responder which Parsley has added automatically.




Keep in mind, if you are not returning the AsyncToken from the service and hence from the Command, and if the command is dynamic; Parsley will remove the Command reference from the context as soon as control will return from the execute method. Otherwise it will retain it till it gets the result or fault call on AsyncToken>responder.

Another point is that any object in Parsley is not able to capture the event if it has already been removed from the context. So any object should be alive with Parsley context to be a part of framework and to be managed by Parsley, only then it will be eligible for the events and other facilities. 

Dynamic Commands with Parsley

Parsley provides dynamic commands feature where it creates a new instance of command on triggering of a matching event. Dynamic commands means the command instances which will be created dynamically by Parsley at runtime, whenever it finds any event in the system matching with 'selector' attribute of the command.

So instance of the dynamic command is dependent on the system state. If at anytime, the required event has been fired, the parsley will create the instance of corresponding Command and will handover the event to it. 

Dynamic Commands can be singleton or non-singleton. This behavior can be controlled by setting  'singleton' attribute with configuration file while defining the Dynamic Commands. In case of singleton commands, Parsley retain the instance of Dynamic Command once it is generated and always hand over the event to same instance. However for non-singleton command, Parsley creates a new instance of Command every time it gets a matching event. 

One should use 'selector', 'execute', 'error', 'result', and 'singleton' attributes while defining the dynamic commands with configuration file. Alternative approach is to write these tags in code file on the methods. We found that sometime 'error' tag specified with code file is not working properly, hence we followed the configuration file approach. 

Execute function of the command can return 'void', 'AsyncToken' or a 'Task'. We assume that command is interacting with service for some database interaction or for business logic. 
  • void - If service is not returning anything, return type can be void for command execute method. 
  • AsyncToken - If it is returning a asynchronous response, an AsyncToken should be returned. It will invoke the command result and fault handlers whenever it will get the result. 
  • Task - If we want to execute some task on command result, one can return the Task object which can perform the required task. 

MVCS Design implementation in Flex and/or Parsley - II

This is in continuation of the last blog for MVCS implementation using Flex and Parsley.

We have discussed various design for various layers in MVCS. Another approach is:

  • View are having reference of Presentation Model. Better to inject the PM using Parsley DI, however as per requirement, these can be instantiated using constructor also. 
  • Commands are having reference of Service. Services are injected using DI. 
  • Commands are dynamic and non-singleton in nature, and hence every event will result in creation of a new command. Parsley framework will automatically create a new command for every event, and hand over the event to it.
  • View can interact with commands using events, and can pass the PM to commands by putting it in Event. 
  • As commands are non-singleton and existing one per event, so now commands can retain the instance of PM till these get the response back from asynchronous service request in result handler. In result handler, command can use the retained PM and update the state of the PM and hence of the view.
  • Command can interact with view or Model using events. However Model and View need to put the check for the events to filter out the events targeted for other UI of same type.It can be done by putting a check for the PM, as command are having the instance of PM, so same can be passed to view or model with event to filter the required event. 
This design considers all the features given by Parsley and Flex and provide flexibility in terms of interaction among layers.