with a programing language like ClojureScript, we have multiple paradigms to deploy to tackle different kinds of design challenges and come up with an optimal solution to each challenge.
It's hard to see how using a single-paradigm tool like FSM or SFSM or even EFSM (the most robust FSM which tackle the complexity of web software creation [1]) can deal with the novel challenges I run into when building a cutting edge web app (e.g. real time, complex interactive data visualizations) When was the last time when you've worked on a novel feature and did not meet a novel challenge? Novel challenges abound in R&D oriented product development and they are best dealt with when you have multiple paradigms that you can deploy against it. If you're building cookie cutter, conventional, no thrills web apps, then there are many single-paradigm tools that can be used, including but not limited to FSMs. 1. https://books.google.com/books?id=zvNvk-1OuBoC&pg=PA10&lpg=PA10&dq=stack+based+efsm&source=bl&ots=uIQZJAxkx3&sig=paxzhNUxozOVynvJxmGlSKINMh0&hl=en&sa=X&ei=DlxaVdfLJo3aoAT-_4CYBQ&ved=0CC0Q6AEwAg#v=onepage&q&f=false On Mon, May 18, 2015 at 1:51 PM, Khalid Jebbari <khalid.jebb...@gmail.com> wrote: > 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 <khalid.jebb...@gmail.com > > 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 <marc.fa...@gmail.com> >> 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 < >>> khalid.jebb...@gmail.com> 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 <marc.fa...@gmail.com> 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 <khalid.jebb...@gmail.com> >>>> 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 <dkers...@gmail.com> 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 <marc.fa...@gmail.com> 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 <sean.tempe...@gmail.com> >>>>> 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 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. >>>>> >>>>> -- >>>>> 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. >>>>> >>>> -- >>>> 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 >>>> 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. >>>> >>>> -- >>>> 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. >>>> >>>> -- >>>> 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 >>>> 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. >>>> >>>> -- >>>> 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. >>>> >>> >>> -- >>> 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 >>> 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. >>> >> >> > -- > 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. > -- 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.
