Indeed I was thinking during the while about the last project I participated, a classical web site with e-commerce processes and forms, for which FSM would have been useful (both client side and server side). I agree with you, there's no silver bullet when we consider the variety of applications possible on the web platform.
> Le 18 mai 2015 à 23:54, Marc Fawzi <marc.fa...@gmail.com> a écrit : > > 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 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.
