State Machine and MVC?

I'm just learning to implement the state pattern which looks very promising for creating user interfaces that adapt to different application states. I use Model View Controller a lot and I'm wondering what the best way to get these two to work together is. The source material I have been learning the state pattern from doesn't really do anything visual, and my primary reason for using it is to make interface changes (disable buttons, etc) based on the state. So my question is, where does it fit in with the MVC pattern?

It really depends on what you want to do. Some people abuse the state pattern and try to create workflows from it. So, if you want to create a set of page flows the state pattern shouldn't be used.

The component-model has been gaining a lot of traction as a replacement to MVC, and can be thought of similarly to service-oriented designs used in the back-end. Instead each widget knows how to display itself, handle its data, and business logic and the page is simply wiring them together. Then you can use the state model in a widget to help organize the business logic. This would be a fairly clean approach to adopting it.

The big problem with the state model is that it doesn't scale very well. It works great for small sets and then combining components, which is how it is done in hardware. Software developers often create large the state models (such as workflows) which eventually causes the model to break down and the code to become unmanagable.

Actually, I just found this article on the subject when skimming over blogs (via dzone.com). You may find it useful, though I think they abused the state model.

Thanks for the reply and the link. So what you are saying is that the state pattern tends to work best for small, encapsulated pieces, such as components but not for keeping track of states of larger things (like the entire application)? I am working on an application where some ui elements function differently depending on the status of the user's network connection. Wouldn't it make sense to use several states to manage the application (online and offline) or is this overkill?

You can always seperate application states from component states, and allow the relevant application states to be input properties for the component. The components could then behave correctly and still own all MVC aspects. This is better than putting all states at the application level and thus spreading the MVC details across the entire UI layer.

In this case, the 'degraded mode' isn't really a state-pattern state. Its just an execution mode. Some frameworks, such as JSF, have different "renders" to allow components to know how to display themselves. This rarely works well, though, because most sites that care would want entirely different page behavior (e.g. mobile).

I'm a back-end developer, not a UI guru, but that would be my approach. Its much easier to separate concerns and deal with fewer variables at once. The UI frameworks generally make you deal with everything at once, which is why they break so often.