A proposal - moving some things out of mx.rpc into mx.async?

Question

Hey guys,
Just want to get your thoughts rather than jump in and filing a feature request. What do you think about moving a few things that aren't necessarily RPC out of mx.rpc and into a new package (for example mx.async) and removing some of the service-related assumptions? A couple of candidates for this in my mind would be:
AsyncToken - I use this for all sorts of Async stuff, which is usually waiting on a service, but not always.
IResponder - This is useful for things such as command chains, and listening in to user actions, and the like. I would also like to see IResponder.applyFault() and IResponder.applyResult() be taken out of mx_internal (and their parameters changed from event types to something else, perhaps Object for result, and Fault for fault).
And the various impls of IResponder as well :)
Just an idea that's been bouncing around my head, thought I'd throw it out there and see what you guys think - worth filing a feature request?
-Josh
"Therefore, send not to know For whom the bell tolls. It tolls for thee."
http://flex.joshmcdonald.info/
:: Josh 'G-Funk' McDonald
:: 0437 221 380 ::
[email protected]

Answer 1

Nice, well while you're in there, any chance we can get FaultEvent from send() dispatching on next frame like a normal event (and on the AsyncToken as well as the WebServie)? I've got some *ugly* workaround code because the fault is dispatched (and handlers invoked) before send() returns, and you can't listen to invocation faults on the AsyncToken like normal events:
            //This code is to catch invocation problems, since Flash has decided to interrupt the flow of the VM for
            //FaultEvent rather than dispatch it on next frame from the token
            operation.addEventListener(FaultEvent.FAULT, invocationFaultHandler);
            //Send the request
            log.debug("Sending request...");
            token = operation.send();
            log.debug("...Send attempt completed");
            //Remove our invocation fault listener
            operation.removeEventListener(FaultEvent.FAULT, invocationFaultHandler);
            //Do we need to send this info on to the token's listeners in a frame or two?
            if (invocationFaultEvent) //Instance-level global
                log.debug("There was an invoke error, which means the token listeners aren't notified. Will redispatch to them in 250ms");
                //When we create the timer, we're using a hard listener reference because this helper instance may otherwise be collected before we're done!
                //So make sure to remove the handler (and kill the timer) on firing!
                timer = new Timer(250, 1);
                timer.addEventListener(TimerEvent.TIMER, reDispatchInvocationFault);
                timer.start();
            return token;
Cheers,
-Josh
On Wed, Oct 1, 2008 at 10:49 AM, Matt Chotin
<
[email protected]> wrote:
A new message was posted by Matt Chotin in
Developers --
 A proposal - moving some things out of mx.rpc into mx.async?
I'm not sure the changes are in Iresponder as much as in a new impl class, but we're looking at making the service classes accept an Iresponder as the last arg to send(...) (where we'd look at the last arg and if it's a responder pull it off).  This can make some of the declarative stuff that we're looking at a little easier.  So any APIs we do would just be to assist in the wiring up of all this stuff.
Not sure when we'll have a writeup for it, a lot of it is do to features in the IDE and we're not sharing those yet :-)  But I'm hoping that I can get that team to provide a writeup in a few days.  Admittedly, the changes we're making are for RPC, not for independence from it, so we'd have to see if it makes sense to do both.
Matt
On 9/30/08 5:38 PM, "Josh McDonald" <
[email protected]> wrote:
A new message was posted by Josh McDonald in
Developers --
 A proposal - moving some things out of mx.rpc into mx.async?
Don't really care about the package name thing, mainly just about changing some of the things that make them less useful when you not actually using mx.rpc.*
What can you tell us about the changes to IResponder coming in Gumbo? I know the UM extensions to Cairngorm use it for callbacks on generated events. I use it for the same purpose, and also as part of an implemtation of command chains, where each invocation takes a context and an IResponder, and it's up to the impl to call Result or Fault.
-Josh
On Wed, Oct 1, 2008 at 4:27 AM, Matt Chotin <
[email protected]> wrote:
A new message was posted by Matt Chotin in
Developers --
 A proposal - moving some things out of mx.rpc into mx.async?
So it probably would have been better if we had created mx.async or used utils for these before, but I don't know that repackaging is a great idea at this point since it will make migrating code forward harder.
The applyFault/Result stuff may be reasonable, we're actually looking at some work in Iresponder as part of Flex 4 (more of another impl that we'll provide) so we can see as we do it.  Do other people use these classes and want these kinds of adjustments?
Matt
On 9/29/08 7:23 PM, "Josh McDonald" <
[email protected]> wrote:
A new discussion was started by Josh McDonald in
Developers --
 A proposal - moving some things out of mx.rpc into mx.async?
Hey guys,
Just want to get your thoughts rather than jump in and filing a feature request. What do you think about moving a few things that aren't necessarily RPC out of mx.rpc and into a new package (for example mx.async) and removing some of the service-related assumptions? A couple of candidates for this in my mind would be:
 *   AsyncToken - I use this for all sorts of Async stuff, which is usually waiting on a service, but not always.
 *   IResponder - This is useful for things such as command chains, and listening in to user actions, and the like. I would also like to see IResponder.applyFault() and IResponder.applyResult() be taken out of mx_internal (and their parameters changed from event types to something else, perhaps Object for result, and Fault for fault).
 *   And the various impls of IResponder as well :)
Just an idea that's been bouncing around my head, thought I'd throw it out there and see what you guys think - worth filing a feature request?
-Josh
View/reply at <
http://www.adobeforums.com/webx?13@@.59b69e6f/0>
Replies by email are OK.
Use the unsubscribe form at <
http://www.adobeforums.com/webx?280@@.59b69e6f!folder=.3c060fa3 <
http://www.adobeforums.com/webx?280@@.59b69e6f%21folder=.3c060fa3> > to cancel your email subscription.
View/reply at <
http://www.adobeforums.com/webx?13@@.59b69e6f/2>
Replies by email are OK.
Use the unsubscribe form at <
http://www.adobeforums.com/webx?280@@.59b69e6f!folder=.3c060fa3> to cancel your email subscription.
"Therefore, send not to know For whom the bell tolls. It tolls for thee."
http://flex.joshmcdonald.info/
:: Josh 'G-Funk' McDonald
:: 0437 221 380 ::
[email protected]