On Tuesday, May 19, 2015 at 3:13:23 AM UTC+10, Daniel Kersten wrote: > From my understanding of it: > > Use higher level states and decouple them somewhat from the data. > > For example, games do have lots of dynamically changing data. In a modern > shooter you might have dozens of characters with positions, orientation, > velocity, health information, weapons, ammunition, etc all of which can be > constantly changing. And that's just taking the characters into account. > > I wouldn't go and build a state machine that enumerates all of the possible > transitions from a "twelve characters with done distribution of attributes in > this location moving in that direction" state. I'd break it down so that each > character has a high level state like "seeking powerup" or "running". > > Probably not a great example although it does illustrate that you might have > a hierarchy of state machines. In the game example, the highest level might > be something like "in play" or "paused" and the lowest might be an each > characters "firing weapon". > > In client side web app, you could say that each configuration of data is a > state (the re-frame readme mentions that you could think of the app-db like > this), but I think that's too fine grained to be useful. > > Instead I'd define higher level states (possibly in a hierarchy). I'd ask > myself, regardless of the data available, what are the logical states that a > user could be in and for each one, what are the actions that they can perform > (and what state does each action transition them to). > > This could be as simple as pages and links, but with a rich single page > application it's more likely finer grained than that. Maybe what dialogs or > widgets are accessible. > > Again, you could then layer these into a hierarchy of state machines. > > One advantage of this is you always know what a user can do at any given time > because you can look at what state they're in. > > I think of FSM states as orthogonal to the data, not as the data itself. The > states dictate what data is accessible and what can be done to it; the data > doesn't dictate what state the application is in. > > I suppose terminology gets confusing, but this is the approach I'm toying > with. I'll see how that goes :)
As Kevin Lynagh said earlier in this thread, the best book around on this subject is Horrocks': http://www.amazon.com/Constructing-User-Interface-Statecharts-Horrocks/dp/0201342782 Kevin also mentions a book I've not read yet: "Practical UML Statecharts in C / C++". -- Mike -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
