OK, implemented changes, and refactored into the multicore package.

for now, down load alpha from my google code page:

http://code.google.com/p/puremvc-utilities/downloads/list

got the demo, but need to do some documenting... am off to Mexico for two weeks though, so I may no to able to do this till I get back

re chaining util... does it have to re-register?? does my hack break another aspect? (see your Chaining Utility post) why can't it declare all its interests on initial registration?

re state machine.. go for it :)

I noticed that the body and types weren't getting passed to the next command in the chain, again, this might be dealt with in the actions, but I thought I'ld post my fix here

public function nextAction(node:ChainNotifierNode=null):void
{   
   if(current >= listenersArray.length-1) return;
   current++;
   doSendNotification(current, node);
}
added a second, optional param to soSendNotification, the lastNode:

public function doSendNotification(index:int=0, lastNode:ChainNotifierNode=null):void    
{   
   if(listenersArray.length == 0 || listenersArray.length < current) return;
   var node:ChainNotifierNode;
   var name:String = listenersArray[index]; //get node name
   node = chainAssocArray[ name ] as ChainNotifierNode; //get node
   if(lastNode == null){
      sendNotification( node.notifySender, node.notifyBody, node.notifyType );
   }else{
      sendNotification( node.notifySender, lastNode.notifyBody, lastNode.notifyType );
   }
         
}
I don't know how this will affect adding body and type in the addNode method, as I'm not doing that, just passing a body along the chain

cheers

well, to tell you the truth, I probably couldn't find a use for such Notifications (which is probably why I didn't have them).  I just figured for completeness. So if you think they are superfluous I'll ditch the idea until someone gives a good reason.
:)

here is a fix for the listNotificationInterests

 override public function listNotificationInterests():Array
      {
         if(listenersArray.length == 0 ) return []; //nothing to do
         var chainName:String = null;
         if(paused == false) chainName = listenersArray[current];
         var actionsAndListerners:Array = actionArray.concat(listenersArray);
         return actionsAndListerners;
      }

NB the change is here: var actionsAndListerners:Array = actionArray.concat(listenersArray);

I don't know how it effects the actions... I haven't looked at them.

also a feature request:

instead of this:
chainNotifier.addNode(NotificationNames.INITIATE_ACTORS, NotificationNames.ACTOR_INITIATION_COMPLETE );

can we have this:
chainNotifier.addNode(NotificationNames.INITIATE_ACTORS, InitActorsCommand,  NotificationNames.ACTOR_INITIATION_COMPLETE );

the ChainNotifier registers the Commands with the facade (and removes them afterward?), which means that all the information is available in the one place.

cheers :)

cool, will implement those

also thought that it might be handy to send some notifications
ie EXITING_PHASE
TRANSITION_PHASE
ENTERING_PHASE

hi cliff

another one for your very long queue (if you like it) :)

a very simple implementation of a State Machine which I have found very useful in combination with trilec's chain utility to manage my command structures.

code on my google code svn here: http://code.google.com/p/puremvc-utilities/

and a quick tutorial on my blog, here: http://revisual.co.uk/?p=237

cheers

hey, trilec
been trying out your chaining util.. nice and simple and very useful, thanks

I did think that it might be a bit difficult to standardise, and you are quite right it probably would end in debate.
We are an opinionated lot

btw IEncodeable, I think is a java one, allowing recursive serialisation of collected value objects:

function encode():*
function decode(data:*)

but there are other ones that do the same but with different names...

Hi cliff

just wondering what you thought of the idea of having some kind of top level interface package in the utilities package.
I was thinking of future proofing issues... as in you have lots of people writing some great utils, and some way of promoting loose coupling between them would be great. I mean what happens if I want to use an existing util in one that I am writing, but don't want to couple it tightly to it, so they have to be used together.  Also common interface like IFactories and IEncodeables could use the same interface throughout the utils package.

this would of course need to be standardised and mediated.

i hope this has made sense.

what do ya think?

hi trilec, have seen that you've done some stuff on chaining commands

I've been working on a prototype that will encapsulate all command chains into a central data source
and will also allow non-linear chaining of commands. 

Just thought i'd say hi, and make you aware of it (I don't want to work on a problem that someone else has fixed), been blogging about it a bit here http://revisual.co.uk/?p=172 , and I'd be interested in your comments as to whether its a good idea, usefull etc.

cheers

and the first of my tutorials are here

http://revisual.co.uk/?page_id=189

apologies, thats the wrong link!! <:/

http://revisual.co.uk/?p=172

http://revisual.co.uk/?p=169