Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1] 2 3 4
Print
Author Topic: AsyncCommand - A PureMVC / AS3 Utility  (Read 76617 times)
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« on: November 12, 2008, 06:37:02 »

The AsyncCommand utility offers a solution to the problem of executing a series of commands each of which may need to complete one or more asynchronous operations before the next command is executed.

The utility has historically been located here: http://trac.puremvc.org/Utility_AS3_AsyncCommand
The project has been moved here: https://github.com/PureMVC/puremvc-as3-util-asynccommand/wiki

Standard and MultiCore versions are included.

The author is Duncan Hall.
« Last Edit: September 23, 2012, 12:50:11 by puremvc » Logged
mister_t
Newbie
*
Posts: 1


View Profile Email
« Reply #1 on: November 25, 2008, 12:14:37 »

Is there also an action script (as3) version of this utility? As far as I know flash can't import .swc files with only class definitions in it.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: November 25, 2008, 12:41:26 »

Yes, for flash, simply put the classes in your classpath. Checkout the release notes page for the AS3 port for info about the varios ways you can do this.

-=Cliff>
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #3 on: December 10, 2008, 08:16:01 »

feature request:

mmm I really want a pre nextCommand hook:


public final function execute( notification:INotification ) : void{
    note = notification;
    onCommandEnter()
    nextCommand();
}

protected onCommandEnter():void{}

any chance?? :)
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #4 on: December 10, 2008, 08:41:36 »

better make it onCommandEnter( notification )
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #5 on: December 10, 2008, 08:43:04 »

so I can do this:

override protected function onCommandEnter( notification:INotification ):void{
   var note:INext;
   note = notification as INext
   addSubCommand(note.getNext())
}
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #6 on: December 10, 2008, 10:52:43 »

Hi Fleecie,

I see what you're after, but it seems like an edge case. I gather you want an AsyncMacroCommand to open a Notification and use it to dynamically discover the next command.

In the example you give, presumably the next command hasn't been defined yet and is not actually being added to the end of a long list of sub commands. Otherwise there'd be no point in doing this evaluation for each command in the list. It would fail if each notification didn't return a new command to be added, so execution of each command in the list would end up adding another command to the list? Seems like it could get out of hand pretty quickly.

I think it's possible that you might find what you want by using the StateMachine utility in conjunction with the AsyncCommand utility. With the StateMachine, you get notification that you're exiting one state and another that you're entering the next, and you can cancel a transition from the exiting notification.

-=Cliff>
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #7 on: December 10, 2008, 01:13:10 »

I thought you might say something like that :)

hey hold on your right! looking at it again, i see that I've made a huge error... I actually want to extend the nextCommand()   thus:

 override protected function nextCommand():void{
var note:INext;
         note = notification as INext
         addSubCommand(note.getNext())





« Last Edit: December 10, 2008, 02:28:07 by fleecie » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #8 on: December 10, 2008, 02:33:54 »

That looks right.

-=Cliff>
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #9 on: December 10, 2008, 02:54:44 »

sorry, had a server error this is the whole post


actually want to extend the nextCommand()   thus:

override protected function nextCommand():void{
    var note:INext = notification as INext;
    var nextClass:Class = note.getNext()
    if (nextClass != null)   addSubCommand(nextClass)
    super.nextCommand();

}

In this way the subcommands would be created dynamically instead of through the initializeCommand() method.  I completely see that this is a very specialised and unique case that doesn't really warrant a change.  It would just be a nicer to extend the AsychCommand Utility from a swc than create "parallel" code

cheers




Logged
willw
Full Member
***
Posts: 30


View Profile Email
« Reply #10 on: March 11, 2009, 03:49:36 »

I think there is a bug in AsyncCommand.as.

The example code only considers AsyncCommand instances being invoked from an AsyncMacroCommand.

If an AsyncCommand is not run from an AsyncMacroCommand, then setOnComplete() is not called for that instance, and onComplete remains null. So when the code in AsyncCommand calls commandComplete() to indicate it has finished, the code barfs.

The cure, I suggest, is to test for an uninitialised onComplete member in commandComplete(), like this:
:
/**
 * Notify the parent <code>AsyncMacroCommand</code> that this command is complete.
 * <P>
 * Call this method from your subclass to signify that your asynchronous command
 * has finished.
 */
protected function commandComplete () : void
{
if (onComplete != null)
onComplete();
}

After this, AsyncCommands can be used standalone and in macros.

Will
Logged
Tekool
Sr. Member
****
Posts: 192


View Profile WWW Email
« Reply #11 on: March 11, 2009, 04:49:55 »

Willw, it's up to you to call the onComplete handler from a standalone AsyncCommand instance.

Look at the comment :

* Call this method from your subclass to signify that your asynchronous command
* has finished.

So it's not a bug. The class do not know the logic that drive to the end of the execution of the asynchronous process, the instance have to call *onComplete* itself to notify of the end of the asynccommand execution.
Logged
willw
Full Member
***
Posts: 30


View Profile Email
« Reply #12 on: March 11, 2009, 05:08:30 »

So it's not a bug. The class do not know the logic that drive to the end of the execution of the asynchronous process, the instance have to call *onComplete* itself to notify of the end of the asynccommand execution.

1. You seem to be confusing commandComplete(), a protected method, and onComplete, a private instance variable containing a pointer to a function. It is commandComplete() that one is supposed to call - onComplete is not in scope in an inherited class.

2. Yes, it is a bug. If the inherited code (correctly) calls commandComplete() from a standalone AsyncCommand (ie not run as a macro) to notify end of execution, then onComplete is null, and the program dies.

Will
Logged
Tekool
Sr. Member
****
Posts: 192


View Profile WWW Email
« Reply #13 on: March 11, 2009, 05:50:28 »

@willw You're right, you must understand *commandComplete* not *onComplete*.

To be honnest, I can't see the context where you need an AsynCommand to call *commandComplete* without to have a wrapper that declare the *onComplete* callback like in the AsynMacroCommand. But you're right, your patch will prevent any use of the AsyncCommand as a SimpleCommand.
« Last Edit: March 11, 2009, 05:52:47 by Tek » Logged
willw
Full Member
***
Posts: 30


View Profile Email
« Reply #14 on: March 11, 2009, 06:00:45 »

To be honnest, I can't see the context where you need an AsynCommand to call *commandComplete* without to have a wrapper that declare the *onComplete* callback like in the AsynMacroCommand. But you're right, your patch will prevent any use of the AsyncCommand as a SimpleCommand.

The point is that a AsyncCommand shouldn't care whether it is being used standalone or as part of a macro. It should work either way, without needing to change its behaviour. For example, you may design an AsyncCommand to be used by itself, and subsequently add it to a macro.

Will
Logged
Pages: [1] 2 3 4
Print