Moving away from CommandChain

[odoe]

Swiz has been great in helping me organize my work and I know there
has been a push here to move away from invoking Swiz in apps outside
of the SwizConfig. Autowire and Mediate meet pretty much all my needs
in my app and I love the simplicity of setting up my service items in
my Beans. I also like the fact that Swiz is as minimal as possible in
my apps.

One issue I am running across is multiple asynchronous commands. The
CommandChain in the docs seems to handle what I'm trying to do, but
I'm looking for an alternative approach.

I have 2 AsyncTokens that use same function to handle the results of
an Asynchronous Service.

AsyncToken( mapQueryDelegate.executeSewers( query).addResponder( new
Responder( zoom_results, query_fault ) ) );

AsyncToken( mapQueryDelegate.executeManholes( query).addResponder( new
Responder( zoom_results, query_fault ) ) );

If I just run them as is, they will work, but with large queries, I
get some overlap that causes some issues.
Without using CommandChain, is the only way around this to call the
second AsyncToken from a function?

Granted my Async-fu may not be top notch, but I'm having trouble here.

[odoe]

Well, leave it to me hitting submit to have a moment of clarity of my
situation.

AsyncToken( mapQueryDelegate.executeSewers( query).addResponder( new
Responder( first_results, query_fault ) ) );

function first_results( featureSet : FeatureSet, token : Object =
null ) : void {
zoom_results( featureSet, token );
AsyncToken( mapQueryDelegate.executeManholes( query).addResponder

( new Responder( zoom_results, query_fault ) ) );
}

I just made a function in my function, when I get my first results
back, pass them manually into my default resulthandler and then call
my second AsyncToken.

This works. I'm not sure it's very pretty though.

[John Yanarella]

Not sure I follow.  If you are wanting to chain two async calls one after another, why not configure the chain to run as a series:

var chain:CommandChain = new CommandChain( CommandChain.SERIES );

chain.addCommand( createCommand( mapQueryDelegate.executeSewers, [ query ], zoom_results, query_fault ) );

chain.addCommand( createCommand( mapQueryDelegate.executeManholes, [ query ], zoom_results, query_fault ) );

chain.proceed();

I see two benefits to going that route: 1) the result is more readable 2) your result / fault methods are reusable and self-contained and don't need to know anything about the chain(s) that call them.  

Are there specific limitations / issues that are keeping you from using CommandChain?

Best,

-John

--

You received this message because you are subscribed to the Google Groups "Swiz Framework" group.
To post to this group, send email to swiz-fr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/swiz-framework?hl=.

[odoe]

You're right. The CommandChain does work well in this situation, but I
did leave out one item. In between the Asynchronous calls I needed to
change a value before calling the next one.

AsyncToken( mapQueryDelegate.executeSewers( query).addResponder( new
Responder( first_results, query_fault ) ) );

function first_results( featureSet : FeatureSet, token : Object =
null ) : void {
zoom_results( featureSet, token );

query.outFields = [ "NAME" ]; // VALUE TO CHANGE

AsyncToken( mapQueryDelegate.executeManholes( query).addResponder
( new Responder( zoom_results, query_fault ) ) );
}

Although, I can just use two different instances of the query object
to take advantage of the CommandChain and it works.

Thanks.

[Gareth Arch]

That will work fine with the CommandChain, also. Why not just use
your first_results method as the 2nd command in the CommandChain?
This will get called when the result from the first command completes
(as long as you run them in series). At that point you will have your
data back from the first command and you can manipulate it however you
like before calling the 2nd command.