is only called when a Mediator is registered and will therefore only be useful if you remove the Mediator and then reregister it

Yes, that makes perfect sense. But the catch is that it gets called only at register time.
The problem with the ChainNotifier is that it assumes that listNotificationInterests is called after it's every nextAction call. That does not happen. The bug kicks in wen you have over 2 nodes added. Works for just 2 nodes.
So it needed some tweaks to work fine.

Not working for me.
Right now I think that it actually does not listen to the 2nd node's notifyListener at all.
This makes sense because at register time the chain's listNotificationInterests() returns only the 1st node's notifyListener.
Upon each nextAction the view should actually refresh the observers and create a new observer that links the chain and the notification of the current action.
Does this happen?
Can the framework handle dynamic listNotificationInterests ?

addNode adds only the first one.
I verify this by tracing the listNotificationInterests().

Hmm, actually the class handles the listeners differently. All are there but I think it's supposed to activate them one by one.
Still it doesn't advance to the 2nd node notifyListener...

And should it work for singlecore if  I just remove the multicore from the path at:
import org.puremvc.as3.multicore.interfaces.*;
?

This notifications chaining looks really handy indeed.
I am on the way to implementing it in my AIR client for a REST service.
Right now I am making a chain for getting the general data ( list of projects for my ProjectsProxy, list of PostTypes for my PostTypes Proxy, ... ).
I am putting these app level logic chains in the app mediator. In the logic there are certain notifications that will trigger one of the chains. For instance the above one is triggered when my AuthProxy emits a "LoginSuccess" notification.
I was browsing trough the class code but I want to doublecheck with anyone who used this succesfully and has a bit of more indepth knowlege.
Would it be ok to put the chains as properties of my app mediator. Init them in the constructor and register them when needed ( when a certain notification is received in the handleNotification of my app mediator )?
Is there a way to register it but start it later. Or maybe creating the chains when needed using var chain = new ChainNotifier() makes more sense and is the intended way of usage?

cosmin

Hello Cliff and thank you for the reply
Since I skipped the usual "hello first post" let me just say here that I just love all that PureMVC is right now. Great code, great docs, great feedback.

Now regarding the problem at hand:
The API is REST it allows a pretty good separation of projects logic and todos logic for instance. Each todoList has it's own id and u can CRUD it just using that. Well for the C part u need the project id Thinking about this yesterday it's quite clear that the server side already incorporates a great deal of domain logic so the inter proxy comm would mostly be "hey, I changed a bit here and here so u might need to update yourself".
While keeping the array of TodoListVO s as a property of a ProjectVO (project hasMany lists) is natural this might become a problem for more complex data relations. So I think that if the proxies can talk one to the other then I will make each handle one of the data types.
Hmm, right now it's obvious that I'm thinking of the Proxy as a DB table Proxy. Does this seem flawed to anyone?
Well not really a DB table proxy. More a data type proxy. Which should fit the model idea. I think. I won't have a proxy for a table that holds the project types...

Regarding a proxy for each of the project's TodoLists.
How would I manage the creation of many proxies? How does the framework help with the factory thingy. Would this be a job for the ProjectsProxy?

cosmin

Problem:
   1. we have a relatively large server application that exposes a REST API. Let's call it Basecamp
   2. we have a structure of Projects, TodoLists and Todos. These are separate tables in the database design. Each TodoList belongs to a Project and each Todo belongs to a Todo list. We use VOs on the client side so we have strong types.
   3. when designing the Proxies, we start with the projects proxy. Now we thing about the Todos and where to keep them.

Question:
   how do we handle the fact that Projects have todoLists in our models design?
   Do we put the todo lists as a property of the Project VO
   or
   Do we keep a separate TodoLists Proxy and use the mediators to connect a project to it's todo lists from the TodoLists Proxy.

The base issue is that the connection between projects and TodoLists is domain logic so it should be handled by the proxy/proxyes (is it domain logic?). Having 2 proxies would require inter proxy communication. How should this syncing occur in a most elegant way? Inside Commands maybe?

ps: While writing this the idea of a project proxy handling a project's todo lists seems not that bad. But then if everything starts from the project, the projectsProxy will soon grow rather large.
Well, I'm grateful for any ideas you guys might have on this. I hope I managed to describe the problem well enough.

cosmin