|
|
|
| DOCUMENTS |
|
UML diagrammes
FAQ
docs@sourceforge |
Someone said life was boring. Well, take this exercise on state machines and what really happens when you decide (for some reason) to use them to implement the controller of an MVC (Model 2) based (web)application.
Some background statements - you don't really have to agree with them, but for the scope of this pamphlet I blindly accept that
(Q) But what do I mean by environment? (A) Actually the context of the application. It consists of various things (depending on the viewpoint - functions, properties, objects,...), and their behaviour can identify the state of the application. So the state is the environment (at a certain time).
(Q) And why the state is in the environment? (A) If you look at the evironment as a container of things it can surely hold a refernce to an environment manipulator unique for the state the environment is. I think you can use it as the environments' state identity. Well I call this manipulator a state, and store it in the environment, in order to have its name handy for use in various identity functions.
Ok. And obviuosly transitions can switch(change) the state. This is what is usually ment. But the meaning I put behind switch/change is that transitions literally manipulate the 'state manipulator'. They change the state identifier and this way they are responsible for changing the state of an application (as part of their routine). The transitions are identified by the state [they change] and [the event by which they are triggered]. Strictly speaking I've just described two different types of state manipulators. For practical reasons I accept that a state identifies a family of states, possible in between the occurence of predetermined events, which trigger some transitions.
(Q) And how do you translate this from gibberish? (A) Simple. Take the example of the java servlet. For simplicity let's forget about the different scopes and use only the request as our environment of the state machine. You've got (a possibly empty) set of attributes in the request. You can always set new ones or change existing ones using setAttribute. The state object "living in this environment" is responsible for the various hygienic tasks - model update, notification, etc... The explicit event (http request) triggers a possibly permanent modification of the application state - a transition have to revise and eventually change the state, put it in the request, and pass the request to the View, which is proudly presented to the http client. the client reviews the state, does some modifications to it, and passes it with a new event to our servlet. From the request (environment) the state is identified, brought to life ...
Practically the state, the transitions, and all the rest of the evnvironment can be represented bys some objects (beans). They can be interrogated, identified and used by every single part of our framework. I intentionally don't focus here on the view and model part of the puzzle. Each of them can be constructed of a set/hierarchy of components. The controller's responsibility is dual - to do the housekeeping and to change the houses when need.
Well, now even I can't get what I ment. Then it must be really worth it.
|
|