Closed erichocean closed 13 years ago
Ya, I get what you're saying. There is also the need to hook in the statechart into the responder chain in order to automatically handle incoming events and pass them along to the next responder if none of the statechart's current states can handle it. Both need to be folded in together.
Yep. I've done the latter before (and have code if you need help/ideas).
this has now been implemented
render() should be state-aware when Ki.StatechartManager is used in views.
A default render() implementation would dispatch to the view's statechart. (It can easily be overridden by simply implementing render() in the view.)
There are two approaches to dispatching render(). The first (and simplest) is to treat render() like any other actions, and have the deepest state that responds to render() handle it.
The second approach is to walk the hierarchy from root to leaf, in order, giving each state a chance to "render", and then walk it backwards (tags need to be closed). This is more consistent with how states are actually used to render(), and would promote code reuse.
(It would also be nice if, following a state transition, if the state implements render(), if this.displayDidChange() were called automatically.)
Feel free to discuss this further; I'm still working things out (though a solution is necessary).