Asynchronous Token
Consider an enterprise application in which a user can place
purchase orders for some parts and request price quotes from various
suppliers. In this case, the user may click several buttons, resulting in
server-side calls to one or more destinations. On each click event of the
button, a RemoteObject
sends a new
request to the server.
The user hits this button several times to place several orders, which in turn initiates the same number of remote calls. The user can also click different buttons, initiating calls to different destinations. Because of the asynchronous nature of remote calls in Flex, the results from each call can arrive at random times.
When each result arrives to the client, it triggers a result
event, which obediently calls the result
handler function written by an application programmer. So far, so good.
Here’s the million-dollar question: how can the application code map
arriving result objects back to the initial requesters if they can come
back to the client in an arbitrary order? The fact that you place an order
to purchase a Sony TV first and a DVD player 10 seconds afterward doesn’t
guarantee that results will arrive to your Flex application in the same
order.
The goal of the Asynchronous Token pattern is to properly route the processing on the client in response to the data arriving asynchronously from the server.
Because AsyncToken
is a dynamic
class, you can add any properties to this class during runtime, as is done
with orderNumber
in ...
Get Agile Enterprise Application Development with Flex now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.