I was going to suggest what you were thinking, "assign it to an instance variable of the DocumentController class in the deleteDocument method (before making the service call), but this seems more like a hack to me"
Just curious why you would consider that a hack? You could also dispatch a custom event from your controller (in your result handlers) that would request the original VO object from your main app.
I guess there is a more elegant way , it depends on what you consider elegant. I don't know anything about your service helper , but your usage of tokens can be of use. Since the token is a dynamic object , you can set variables on it. So you could set the document on your token. However , it seems as if you have some abstraction between the token and the call , meaning this really wouldn't be possible without shifting some stuff around.
Generally , when I use delegates and helpers , they perform their operation , and then let the rest of the application know whether it was a success or failure. This way , you maintain the reference to your original object ( the document ) and still keep some semblance of control flow. The added benefit is that if you put the service inside of the delegate , or outside of the document controller , you decrease coupling and lend your code to unit testing.
P.S Also , using delegates to do the heavy lifting ( service call and response ... ) as opposed to keeping a reference to the deleted document in the document controller allows you to delete more than one document asynchronously. Then you don't have to worry about matching calls and events to documents , should your application warrant it.
Perhaps "hack" was a poor word choice. It's definitely a viable solution -- and one I'll keep in mind -- but thought there might be a better way to manage it.
Thanks for the suggestions,
I'm using the Swiz framework and this is a common way to decouple the controller from the service. However, it's not specific to Swiz, which is why I posted here instead of their user group.
For my specific example, the service call will delete the document from the backend datastore. If successful, the deleteDocumentResultHandler will then get invoked and be responsible for removing the item from the display (a datagrid) by removing its element from the list bound to the datagrid, which is held in the model. Obviously, to maintain this loose coupling and for unit testing, my service delegate shouldn't be responsible for removing the item from the list.
Given this additional information, would you suggest storing it as an instance variable of the DocumentController class or adding it to the token (how would I do that)?
Turns out the Swiz service helper's executeServiceCall() is able to accept pass-through variables that are then passed to the result/fault handlers, which is exactly what I need.
Thanks for the help, guys!