Regarding SFSMs, it looks like the top-level states would be URLs (in a well behaved application), and the nested ones would be for any widgets inside the pages. Just thinking out loud.
Khalid aka DjebbZ @Dj3bbZ On Mon, May 18, 2015 at 10:49 PM, Khalid Jebbari <[email protected]> wrote: > This is it, Marc. The SFSM diagram represents exactly what I had in mind. > Do you think they're viable in the context of a web app ? As long as they > can be stacked as needed, they could handle any complexity of UIs, no ? > > Khalid aka DjebbZ > @Dj3bbZ > > On Mon, May 18, 2015 at 10:34 PM, Marc Fawzi <[email protected]> wrote: > >> "stack-based" is not exactly "stacked" but I was thinking chip design for >> some reason ( >> http://en.wikipedia.org/wiki/Three-dimensional_integrated_circuit) >> >> The one diagram that made it obvious: >> >> >> http://gamedev.stackexchange.com/questions/25854/gamestate-management-hierarchical-fsm-vs-stack-based-fsm >> >> >> >> >> On Mon, May 18, 2015 at 1:28 PM, Khalid Jebbari <[email protected] >> > wrote: >> >>> Thanks for the clarification, I didn't about them. >>> >>> Now I need even more reading and thinking :) >>> >>> Le 18 mai 2015 à 22:23, Marc Fawzi <[email protected]> a écrit : >>> >>> Back to composability >>> >>> I read about stacked vs hierarchical FSMs and it looks like what you >>> want is a stacked one not a hierarchical one... Subgraphs dont have to be >>> entangled with the global graph >>> >>> Sent from my iPhone >>> >>> On May 18, 2015, at 10:26 AM, Khalid Jebbari <[email protected]> >>> wrote: >>> >>> I like how you break up the state machines, it has sense in web app. >>> Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM >>> associated with it, the higher level FSM knowing just the higher level >>> state of all widget displayed. Mmmh... Interesting. >>> >>> Le 18 mai 2015 à 19:13, Daniel Kersten <[email protected]> a écrit : >>> >>> 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 :) >>> >>> But yeah, needs more thinking. >>> >>> On Mon, 18 May 2015 16:55 Marc Fawzi <[email protected]> wrote: >>> >>>> Games are ideal candidate for straight-forward FSM implementation since >>>> you normally download the data at game load time and from there on you have >>>> a *relatively* small set of states that can be transitioned between based >>>> in user input. You can even apply state minimization techniques to reduce >>>> the total number of states. >>>> >>>> But in a web app you are continuously grabbing data from the server and >>>> that data is generated based on not only user input but also the state of >>>> the server side database and that server generated data would modify UI >>>> side app state and you have to account for all possibilities so the total >>>> number of states could grow wildly if your UI is data driven (where the >>>> state of the UI depends on the data in non-trivial ways) but even if your >>>> UI state dependence on server data was a trivial relationship you could >>>> still end up with a huge state diagram for the simplest viable business app >>>> if you include templating the view as part of the UI FSM on top of business >>>> logic. You could segment your app into micro apps and that will help >>>> regardless of whether you're building the app as FSM or not. >>>> >>>> And what if the state transitions are probability driven? How many >>>> states will you end up having to chart? >>>> >>>> Not convinced YET... >>>> >>>> Sent from my iPhone >>>> >>>> > On May 18, 2015, at 6:57 AM, Sean Tempesta <[email protected]> >>>> wrote: >>>> > >>>> > Hi Khalid. I found your topic interesting so I thought I'd chime >>>> in. Regarding your comments on routing: >>>> > >>>> > So, under normal conditions, the initial URL sets the FSM in motion >>>> (as an event). We could call this entry point a routing state. Afterward, >>>> the state transitions are controlling the urls (not the other way around), >>>> right? >>>> > >>>> > Outside of normal conditions (ie. people copying and pasting links >>>> into random parts of the system), you also just send the url to the routing >>>> state and then switch to a new state based on whatever rules and >>>> definitions you've set. >>>> > >>>> > Or maybe I'm missing something. I haven't built an FSM in a while. >>>> :) >>>> > >>>> > Sean >>>> > >>>> >> On Monday, May 18, 2015 at 6:07:22 PM UTC+8, Khalid Jebbari wrote: >>>> >> Trying to push forward the discussion about Web UI with state >>>> machines. I came up with the following decomposition of the core components >>>> of a web application : >>>> >> >>>> >> - application state >>>> >> - application data >>>> >> - business logic >>>> >> - ui logic >>>> >> - event processing >>>> >> - presentation layer >>>> >> - routing >>>> >> >>>> >> In this schema, I think the application state is the real core, >>>> because every other components is directly related to it, at least if you >>>> use a state machine. I came up with the following model. >>>> >> >>>> >> - application data : related to application state because both can >>>> easily represented as data. If we want a web app that is completely >>>> state-driven (I want this, for debugging, testing and time-travel >>>> capabilities), simply merge the data and the state in the same data entity. >>>> >> >>>> >> - business logic/ui logic : in a state machine there's the notion of >>>> "actions" executed with each transition (where necessary). So the logic >>>> could just be executed by the state machine itself. >>>> >> >>>> >> - event processing : a state machine can be event-driven, and this a >>>> perfect match with a web app since the web (and any UI for that matter) is >>>> inherently event driven. So the event/input of the state machine could just >>>> match the event triggered by the user, as well as custom events if >>>> necessary. >>>> >> >>>> >> - presentation layer : simply display the current app-state as >>>> HTML/CSS. In the React.js model, it would simply mean updating the app >>>> state and letting React render everything. >>>> >> >>>> >> - routing : this is where stuff gets complicated in my mind. In a >>>> proper application, lot of state is derived from the URLs. But not all >>>> state, for instance whether a modal is displayed or not, or whether a form >>>> is validated client side or not isn't tied to a URL. Which tend to let me >>>> think that there's some kind of hierarchy in the state machine. The URLs >>>> could be represented as events as well in the state machine, but could >>>> happen at anytime, whereas other events and related transition depend on >>>> the current state in a state machine. So it's like you have a top-level >>>> state machine for URLs, and each URL has its own state machine for all >>>> interactions in the page. Maybe page-state machine could be refined in >>>> multiple levels state machines too, not sure about that. It seems like >>>> Hierarchical State Machine may help here, but I haven't studied the subject >>>> yet at all. >>>> >> >>>> >> What do you think ? >>>> > >>>> > -- >>>> > 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 [email protected]. >>>> > To post to this group, send email to [email protected]. >>>> > Visit this group at http://groups.google.com/group/clojurescript. >>>> >>>> -- >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/clojurescript. >>>> >>> -- >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "ClojureScript" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/clojurescript. >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/clojurescript. >>> >>> -- >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "ClojureScript" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/clojurescript. >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/clojurescript. >>> >> >> -- >> Note that posts from new members are moderated - please be patient with >> your first post. >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "ClojureScript" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/clojurescript. >> > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
