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 76622 times)
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #30 on: March 18, 2009, 02:32:43 »

Yep, thats what I found when I tried to implement a Asynchronous StateMachine transition using the Mcdaddy: http://revisual.co.uk/?cat=61

« Last Edit: March 18, 2009, 02:43:02 by Neil Manuell » Logged
willw
Full Member
***
Posts: 30


View Profile Email
« Reply #31 on: March 18, 2009, 03:01:09 »

@Cliff: Excellent news that we have resolved this - I was afraid that one or both of us was going mad!

On the general discussion: certainly AsyncCommand and macdaddy (much improved terminology) have the drawbacks that you say. I have not used a macdaddy yet, and expect its application to be quite limited, for the sorts of reasons you say. But I can imagine wanting to make a McSimpleCommand sandwich: say a Simple followed by an Async followed by another Simple.

AsyncCommand I have found to be good in two use cases: calling services, and also for handling modal dialogs.

Modal dialogs don't block the thread, but they do something rather like it, by restricting the user typically to Ok and Cancel buttons. So you get something very like the blocking behaviour. If you have the initial part of an AsyncCommand launch the modal dialog, and have the completion part process the result and take appropriate action, then you have all the logic for your dialog handling neatly localised in one place.

Calling services with AsyncCommand I have discussed at length, I know. But you may have missed my point that using AsyncCommands in this way enables you to remove the notification constants declared in proxies. Why would one want to do this? Because it means that mediators that depend on data from the proxies wrapped up in a VO don't need to import the proxy. Sure, the AsyncCommand does, but it would do so anyway. It means one doesn't have to hunt through proxies for notification constants too.

The drawbacks you mention to AsyncCommands are mostly true (although I have no 'tedious coordination of chained commands', honest), but if you plan for them you discover they may not matter. If the data arrives too late because the punter has changed his mind, then so what? If your app continues to be responsive, even at the hands of an impatient clicky user and a slow data feed, then that is a win.

The main drawback with the approach based on states is: when I tried it I ended up with a LOT of states, in order to cope with all the 'waiting for an answer' situations I needed to handle. I found this was clouding my view of how the whole machine worked. I want to keep the state machine only for very high level features; I found I could push a lot of detail into AsyncCommands and hide it there.

This is of course all extremely subjective and Your Mileage May Vary.

I do feel pretty bullish about the way I have got my app organised. Of course the bedrock is the base PureMVC architecture, which has proved great. I mention this because you may think I lose sight of this point in the heat of discussion - I don't.

Will
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #32 on: March 18, 2009, 05:00:37 »

@willw, True that. Discussions between coders that really love their work can get pretty hot sometimes. That's passion for ya. :)

I can see that if you want a less granular state machine then a combo of the 2 utils is probably the way to go.

@neil, you reported this lack of blocking before as well, I just didn't get the time to put my mitts on the utility until recently.

I have a pretty good sized FSM definition, but I'm happy to have the whole system expressed there. If you think about it, those application states exist, even if you aren't using the state machine. Its just that by using it, you make them concrete. You can look at the FSM definition and see the whole story.

I want to build a middleware tool for creating, visualising and testing the fsm definition. That would make it easier to take the fine-grained approach.

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


View Profile Email
« Reply #33 on: March 19, 2009, 02:33:45 »

@ cliff

I want to build a middleware tool for creating, visualising and testing the fsm definition.

If you wanna farm some code of that out, Id be happy to help...

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #34 on: March 20, 2009, 05:43:40 »

Neil,

I'd be extremely happy to have the help, because honestly, it'll be awhile before I can get to it.  I was thinking of using Flare for visualization: http://flare.prefuse.org/apps/index

Have a look and see if it looks easy enough to work with.

I was thinking it would generate an AS3 file with the static constants in it, as well as an InjectFSMCommand that looks like the StopWatch one where the constants are bound into the XML. Otherwise if you use literals, you still have to define constants that match those literals in order to register the commands or for the mediators to express interest.

-=Cliff>
« Last Edit: March 20, 2009, 05:46:20 by puremvc » Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #35 on: March 28, 2009, 08:29:33 »

have had a quick look at fuse.
will have a more in depth look when I have some time to myself.. which should be in a few weeks ;)
Logged
crypt
Jr. Member
**
Posts: 16


View Profile Email
« Reply #36 on: May 10, 2009, 03:12:02 »

Hi!

I have created a PageChangeCommand (AsyncMacroCommand) with 2subcommand:

addSubCommand( PageHideCommand );
addSubCommand( PageShowCommand );

I would like to hide the current page, and if it is finished, show the next page.

PageShowCommand on execute command:
var page:Page = facade.retrieveMediator(note.getBody() as String).getViewComponent() as Page;
page.showEffect();

PageHideCommand on execute command:
var page:Page = facade.retrieveMediator(note.getBody() as String).getViewComponent() as Page;
page.hideEffect();

But the notification is the same in the 2subcommand...

I use this 2 command (pagehide, pageshow), as standalon command elsewhere in application too.

how can i do this?
thanks!
Logged
crypt
Jr. Member
**
Posts: 16


View Profile Email
« Reply #37 on: May 10, 2009, 11:01:18 »

so the main question is, can I pass different notifications to subcommands?
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #38 on: May 11, 2009, 12:48:40 »

try sending an array of your proxynames as the body of the notification, then each command can pop them off...
Logged
crypt
Jr. Member
**
Posts: 16


View Profile Email
« Reply #39 on: May 11, 2009, 01:13:12 »

thanks! good idea! :-)
Logged
willw
Full Member
***
Posts: 30


View Profile Email
« Reply #40 on: May 11, 2009, 01:20:41 »

In a similar situation recently, I thought of this approach - sending in an array and modifying it - and I would certainly expect it to work.

But I can't help feeling a mod to addSubCommand() would be clearer, though, and more generally applicable. There seems no reason AFAIK why subcommands should not take parameters. It would make them generally more useful and powerful.

Will
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #41 on: May 11, 2009, 01:28:21 »

Well, for the basic pureMVC, I think the solid, simple way is best... and there is always a fairly simple solution for most problems ( and don't for get that commands can modify just the notification if needed ).

However, as an additional "bolt on" utility that builds on the basic, I think that this is a grand idea... over to you Will... :)

(oooh, and while your there, I've also also like the idea of being able to inject subcommands at run time too... that would be awesome! )
Logged
willw
Full Member
***
Posts: 30


View Profile Email
« Reply #42 on: May 11, 2009, 03:56:56 »

don't forget that commands can modify just the notification if needed

The trouble with commands modding the notification is that it means that the command becomes 'aware' of its context. This is also my problem with eating the array of parameters as you go along. It works, but you are spreading knowledge of the parameter mechanism, and the outside environment, into the sub command. The subcommands become more tightly coupled than one wants.

And yes, I would like to come back and have a go at this and a few other things. There are some straightforward mods that I made to to the State machine which I claim improves its decoupling considerably. I would like to share, if Cliff is up for it.

But not today.  Today I am on a code death march! :-o

Will


Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #43 on: May 18, 2009, 03:07:26 »

The trouble with commands modding the notification is that it means that the command becomes 'aware' of its context.

agreed, and you can also add that any code must have some awareness of its environment, but no more than necessary.

The command "knows" the framework, the command is there to do a certain job on a certain object - even if that object is hiding behind an interface, it must know that interface. It must know how to obtain it, whether from the notification body, or retrieving it from the framework.

so what is the difference between passing a proxy name in the body, or an array of proxy names, the command is expecting one or the other or either.

your command could type check the note body, use a string or pop from an array, or an array collection, or a linked list, or whatever. It could even take a leaf from "Chain of Responsibility", and if it can't do its job in the environment it was expecting, it pass the job on to the next command, which may be able to.

what is the difference between passing an array of proxy names in a notification, which is modified by a command and passing a proxy in a notification which is modified by a command? or are you saying that to pass an object in a notification to a macrocommand is to tightly couple its subcommands?  I'm not sure about this.  Also, if any tight-couplings are to appear in your application where better that in your commands, which tend to be (though not exclusively) tightly coupled to the application in which they are implemented.



Logged
willw
Full Member
***
Posts: 30


View Profile Email
« Reply #44 on: May 19, 2009, 03:52:36 »

I am saying that if you require that a command mods a notification in order for the next command to work, you are indeed introducing a coupling between the commands that didn't previously exist. You cannot now introduce 'any' command into the sequence - for example a command that expects a certain VO as its note body (say). It must be a command designed to consume the array of (whatever - proxies in this case).

Whereas, if you have a variation of addSubCommand() that can pass in params (or not, as required) then the subcommands remain quite ignorant of each other's existence, and so can be re-used freely and intermixed with one another in other macro commands or used standalone, without imposing the requirement that they handle the note body in a certain way.

Will
Logged
Pages: 1 2 [3] 4
Print