optimization actionscript state-machine hsm behavior-tree

Best Practice for Transitioning From Nested State to Nested State (see diagram)

I am trying to wrap my mind around the best way to implement nested state transitions in a single threaded programming language (Actionscript). Say I have a structure like this behavior tree:

Now imagine that each leaf node is a destination point on a website, like an image in a gallery, or a comment nested in a post view nested in a page view... And the goal is to be able to run animated transitions from leaf node to leaf node, by animating out the previous tree (from bottom to top), and animating in the current tree (from top to bottom).

So, if we were at the bottom-left-most leaf node, and we wanted to go to the bottom-right-most leaf node, we would have to:

transition out bottom-left-node
on complete (say after a second of animation), transition out it's parent,
on complete, transition out it's parent
on complete, transition IN the right-most parent
on complete, transition in right most-child
on complete, transition in leaf

My question is:

If you imagine each of these nodes as HTML views (where the leaves are 'partials', borrowing the term from rails), or MXML views, where you're nesting sub components, and you don't necessarily know the nest levels from the application root, what is the best way to animate the transition as described above?

One way is to store all possible paths globally, and then to say "Application, transition out this path, transition in this path". That works if the application is very simple. That's how Gaia does it, an Actionscript framework. But if you want it to be able to transition in/out arbitrarily nested paths, you can't store that globally because:

Actionscript couldn't handle all that processing
Doesn't seem like good encapsulation

So this question can be reworded as, how do you animate out the left-most-leaf node and it's parents, starting from the leaf, and animate in the right-most-leaf node, starting with the root? Where is that information stored (what to transition in and out)?

Another possible solution would be to just say "Application, transition out previous child node, and when that's complete, transition in the current child node", where the "child node" is the direct child of the application root. Then the left-most child of the application root (which has two child nodes, which each have two child nodes), would check if it's in the right state (if it's children are 'transitioned out'). If not, it would call "transitionOut()" on them... That way everything would be completely encapsulated. But it seems like that'd be pretty processor intensive.

What do you think? Do you have any other alternatives? Or can you point me to any good resources on AI Behavior Trees or Hierarchical State Machines that describe how they practically implement asynchronous state transitions:

From where do they call "transitionOut" on an object? From the root or a specific child?
Where is the state stored? Globally, locally? What is the scope defining what calls "transitionIn()" and "transitionOut()"?

I have seen/read many articles/books on AI and State Machines, but I have yet to find something describing how they actually implement asychronous/animated transitions in a complex MVC Object Oriented Project with 100s of Views/Graphics participating in the behavior tree.

Should I call the transitions from the parent-most object, or from the child?

Here are some of the things I've examined:

While this is not necessarily an AI problem, there are no other resources describing how to apply nested state architectures to websites; these are the closest things.

Another way to word the question: How do you broadcast state changes to the application? Where do you keep the event listeners? How do you find what view to animate when it's arbitrarily nested?

Note: I am not trying to build a game, just trying to build animated websites.

Solution

I'll try to simplify the problem before suggesting a possible approach. The transitions seem related to the views, and not the model. If I were to skip the transitions and go straight to some other leaf node, the application still works but there is not visual clue for the users. So I'd suggest you use a view-controller specifically to hold the current branch and the transitions of various views.

It's probably a better approach to split the two types of transitions into a sort of stack where a pop transition is to go back to a previous node, while a push transition goes forward in the hierarchy. Apple uses a similar technique to manage navigational applications using a navigation view controller. It basically maintains a stack of view controllers that the user followed to get to a particular node. When a user goes back, the top item is popped off the stack, and the user sees the previous item. If the user goes deeper in the hierarchy, a new view controller is pushed onto the stack.

You would still need a global way to represent the hierarchies in a flyweight manner, while the navigation stack only stores the currently visible branch down to the leaf node.

If a user went from one leaf node to another, the current stack will be popped out upto the common parent. Then the global tree structure will be asked to get the path from that parent upto the new leaf node. This path of nodes is pushed into the current navigation stack, and as each item is pushed, the transition is shown.

In a simple algorithm, there'd be these two data structures and a way to get the entire branch that contains leaf node:

a global representation of the tree
a stack of the current branch

initially:

stack = []
tree = create-tree()

algorithm:

// empty current branch upto the common ancestor, root node if nothing else
until stack.peek() is in leaf-node.ancestors() {
    stack.pop() // animates the transition-out
}
parent = stack.peek();
// get a path from the parent to leaf-node
path = tree.get-path(parent, leaf-node)
for each node in path {
    stack.push(node) // animates the transition-in
}

Update:

The entire application could have a single navigation controller, or multiple such controllers. A navigation controller only needs to know that there is a tree which exposes certain operations. So you could create an interface with those operations and let concrete subclasses implement that.

I can only think of two operations that would need to be exposed (pseudo-Java syntax):

interface Tree {
    List<Node> getAncestors(node);
    List<Node> findPath(ancestorNode, descendantNode);
}

That should provide sufficient abstraction to keep the navigation controller poking inside the global tree structure. To take it to the next level, use dependency injection so the tree object is injected into the navigation controller, improving testability and breaking the tree connection completely.