Backing a user interface with a state machine

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.