Apex Code Development You need to sign in to do that
Don't have an account?
dturkel AsyncResponder: Why and How to use the Context parameter
Hello,
Regarding the AsynResponder in the Flex toolkit, I'm looking for a decent explanation on why I would use the Context object as part of my AsyncResponder setup. I've seen a few posts explaining some past updates to it, but I'd love to understand what I can do with it.
Ultimately I'm trying to build a DAO framework for my application that needs to get data on-demand from SFDC. I then populate control widgets in my Flex application, but I'm having trouble because the AsyncResponder is Asynchronous, and I don't want to build the AsyncResponder block over-and-over again for the same generic queries that might be used accross multiple layouts/controls.
If anyone has any practical examples or advice on a better way to do this, please pass along.
Links to other meaningful posts/articles accepted.
Thanks,
Dave
In a way you have answered your own question... you have mentioned two good reasons why the context object is critical.
1) "I'm having trouble because the AsyncResponder is Asynchronous" - yes, this can pose what seems to be trouble until you get used to it, then all you see are the benefits. The context object is critical in using Async calls elegantly. Think of it like sticking a post-it note on something so that when you come across it a week or month later you will still now exactly what it is for and what to do with it. It could be the ID of the element that made the call in the first place, or it could be additional information that will be needed for the handling function to know what to do with the response.
2) "I don't want to build the AsyncResponder block over-and-over" - exactly, with no context variable you would have to build a bunch of different little callback functions for every single reason you might make a call to the API during execution... each specialized function would know exactly what to do with the API response... and you would have to make sure each call has the correct callback function defined for the purpose of the call. With the context variables, however, you could have one intelligent callback function that could take a variety of responses, inspect the context variable, and take the appropriate action.
A trivial example could be that you have multiple DataGrid components on a page to display various lists of accounts, each DataGrid has an accompanying "Refresh" button. Without context variables you would have to create a callback for each Button/DataGrid pair. But instead, you can create one callback called, say "genericAccountQueryHandler" and then each time you make a query call from any Refresh button, simply put the ID of the button (or some other distinguishing data) into the context object and use your generic function as the callback. The generic function would then be able to inspect the context of every return call and it will therefore know which DataGrid to put the data into.
Of course this is just one simple example... there are a host of other ways to use this object. I think the most important thing to remember is that Async calls do not always come back in the order they are made... so you shouldn't make any assumptions in your callback functions... always pretend like they know nothing and must figure out everything they need from the returned data from the APi in conjunction with the context object.
Hope this helps.
All Answers
In a way you have answered your own question... you have mentioned two good reasons why the context object is critical.
1) "I'm having trouble because the AsyncResponder is Asynchronous" - yes, this can pose what seems to be trouble until you get used to it, then all you see are the benefits. The context object is critical in using Async calls elegantly. Think of it like sticking a post-it note on something so that when you come across it a week or month later you will still now exactly what it is for and what to do with it. It could be the ID of the element that made the call in the first place, or it could be additional information that will be needed for the handling function to know what to do with the response.
2) "I don't want to build the AsyncResponder block over-and-over" - exactly, with no context variable you would have to build a bunch of different little callback functions for every single reason you might make a call to the API during execution... each specialized function would know exactly what to do with the API response... and you would have to make sure each call has the correct callback function defined for the purpose of the call. With the context variables, however, you could have one intelligent callback function that could take a variety of responses, inspect the context variable, and take the appropriate action.
A trivial example could be that you have multiple DataGrid components on a page to display various lists of accounts, each DataGrid has an accompanying "Refresh" button. Without context variables you would have to create a callback for each Button/DataGrid pair. But instead, you can create one callback called, say "genericAccountQueryHandler" and then each time you make a query call from any Refresh button, simply put the ID of the button (or some other distinguishing data) into the context object and use your generic function as the callback. The generic function would then be able to inspect the context of every return call and it will therefore know which DataGrid to put the data into.
Of course this is just one simple example... there are a host of other ways to use this object. I think the most important thing to remember is that Async calls do not always come back in the order they are made... so you shouldn't make any assumptions in your callback functions... always pretend like they know nothing and must figure out everything they need from the returned data from the APi in conjunction with the context object.
Hope this helps.
Thanks very much for the reply. It was useful, and practical -- helped me get the concept through my thick skull.
Dave