I have seen many FSM implementation and workflow implementation in javascript but i couldn't figure out something that exist for Marionette framework or something that goes hand in hand with marionette framework?
I am afraid Marionette may not need such implementation or it may be overkill....given the case it may already doing it in one of their components.
If i need to implement an FSM, do i need look beyond marionette or i can do some simple tweak in one of their components and get the work done.
Thoughts?
The simplest FSM is an object which stores state and emits a signal upon state changes. If this is what you need you can use a Backbone Model for it. If you need a little more complexity here's a few Backbone specific ones:
backbone.statemachine
backbone.fsm
Related
Several months ago I met a flux and I found it's awesome, I love it, I use it.. almost in every new project and when I met a redux I love it even more, but couple of days ago Pete Hunt publish a tweet where he judge the people to use flux for everything. And I think it have a perfect sense, but on the other hand I don't get it.. He publish another tweet where explain cases for flux, also I read an article about use cases for flux. Long story short - "If your app doesn’t have complex data changes and caching, don’t use it. But if it does, I strongly recommend you try Flux." and it's totally make sense for me why I should use flux, but it not clear to me why I shouldn't if I don't have a complex data changes.
In the article Dan point, that when you faced those issues(that flux solve) in real project you can easier to understands the benefits of the flux, but exactly of this(cause I faced with these problems at work project) now I try to use flux in every project, because I don't wanna to deal with it anymore.
And crazy part, that now I often use it also for ui states, not just data changes. Let's pretend I can have a widget component, for example a clock. It can make some ui changes, like show/hide seconds, switch between digital/analog and it has a daytime type state(day/night) and can dispatch an event when it changed, but other component listen it and can react, for example change a background color. I can easily solve it just with local component state and container(smart component) state, but same as I can put all these logic into store(reducers) and components will be really dump and just react on the current state(props) and containers(smart) just listen the store and partitioned state between the components. And if even it looks ok, point that I can use it for every ui state - open/close sidebar, some specific component changes, etc.
Reasons why I can do it:
It looks predictable for me. I completely know that any changes happened in my app serve in one place.
It easy to debug. I can just log all the actions and if I will get some bug, I can easily found what happened and reproduce it.
I can easily expand my app without worrying, mb I should move something to the flux state, cause I already did it.
But also I agree that it's looks overwhelmed and I can solve it without flux, but I can't answer to me, why I shouldn't use flux in these cases. What is wrong with it? Please help me.
let's say I have created several separate FSM classes inheriting from statechart. Then, I instantiate those objects, and I would like them to be able to trigger events in each other; for example the first FSM would enter a "ON" state and would trigger an event in the second FSM (like process_event(EvSomething()) ).
What would be the best method to do that?
Thank you very much,
Fabrizio
The main motivation for Asynchronous State Machines is exactly the scenario you describe. So, I would suggest you convert your machines into asynchronous ones. See here for an example.
I am developing a web application with a somewhat complex user interface. It seems like it might be a good idea to back the UI with a corresponding state machine, defining the transitions possible between various states and the corresponding behavior.
The perceived benefits are that the code for controlling the behavior is structured consistently, and that the state of the UI can be persisted and resumed easily.
Can anyone who has tried this lend any insights into this approach? Are there any pitfalls I need to be aware of?
Off the top of my head, these are a bit obvious, but still, as nobody replied anything:
i'd advise to persist the state of the application server side, indexed via a session variable/user id for security and flexibility reasons;
interfaces are better modeled by an event-based approach IMHO, but this is a bit dependent on what layer of the UI you're developing, and also on your language of choice for development. You may be able to store some logic on item triggers and items themselves.
By event-based approach, i refer somewhat to this technique, which some "more visual" oriented environments (adobe flex, oracle forms and also html, in a sort of limited fashion) use. In a nutshell, you have triggers (item.on_click, label.on_mouse_over, text_field.on_record_update) which you use to drive the states of the interface.
One very common caveat of this kind of approach (distributed control) is endless loops: you have an item that enables another item, which when enabled fires its own triggers and eventually gets the first item to fire that same trigger again. This is quite often not obvious when developing, but very common to detect when testing.
Some languages/environments offer some protection against the more obvious cases, but this is something to be on the lookout for.
This is probably useful for your approach.
I need a GUI control to update whenever a persistent data structure (PDS) is updated.
I need to have the PDS updated when the user takes certain actions.
So, for example, an SWT Tree and a simple tree data structure.
There are lots of manual, ugly ways to do this, but it seems to me this is a very common situation and there would likely be a very clean approach out there.
I've been reading about FRP, Lenses, Actors, etc... seems like there could be a very simple, clean, effective approach to handling this type of situation.
What I can think about is having a component with a mutable reference to the PDS. This component could raise an event with the new version of the PDS every time it changes the value of the var. Your GUI control could be listening to that event and react to it by redrawing itself with the new info. Other option is that the component that listens to the event be the parent of your GUI control, reacting by creating a new instance of it, so the control can receive the PDS in the constructor and draw itself only once.
A persistent data structure never updates. You probably have a reference to a persistent data structure that changes to the new version, when you change it. If you want to track incremental change in the PDS, it's going to be awkward. The thing is, at the point you're storing the new version of the PDS, you still have the old version. Maybe you can run a diff to produce the incremental change.
Yes, there is a nice and clean approach: ValueModels. It should be pretty easy to implement in Scala (I've found nothing in a quick search). AFAIK there is a Java implementation embedded in Spring Rich Client.
How you describe it, it seems that the user calls takes certain actions inside the GUI, and then the GUI and the Database has to be updated. As long as the database update is a side effect you could completely rely on all SWT events.
I am currently refactoring code that coordinates multiple hardware components for data acquisition, and feeling a bit like I'm recreating the wheel. In particular, an MVC-like pattern seems to be emerging. Except, this has nothing to do with a GUI and I'm worried that I'm forcing this particular pattern where another might be more appropriate. Here's my scenario:
Individual hardware "component" classes obey interface contracts for each hardware type. Previously, component instances were orchestrated by a single monolithic InstrumentController class, which relied heavily on configuration + branching logic for executing a specific acquisition sequence. After an iteration, I have a separate controller for each component, with these controllers all managed by a small InstrumentControllerBase (or its derivatives). The composite system will receive "input" either programmatically or via inter-hardware component triggering - in either case these interactions are routed to, and handled by, the appropriate controller.
So, I have something that feels MVC-esque, but I don't know if that's because I'm forcing the point. With little direct MVC experience in application development, it's hard to know if I'm just trying to make my scenario fit MVC, where another pattern might be a good alternative or complimentary. My problem is, search results and wiki documentation of these family of patterns seems to immediately drop me into GUI-specific discussions.
I understand "M means Model data and the V means View" - but what do you call the superset pattern? Component-Commander-Controller?
Whence can I exhume examples exemplary?
IMO a "view" is not necessarily a GUI component. The pattern is easiest to demonstrate with GUIs but that does not limit its usability to GUIs. If it works for you, don't worry about the name :-) And of course, feel free to tailor it according to your needs.
Update: Of more generic kins of MVC, the only example which surfaced in my mind (after a day's background processing) is PAC.