On 6/22/05, Michael Taylor <[EMAIL PROTECTED]> wrote: > Michael, > > It appears from your > articles that your solution depends upon tight integration with the > application model. There are two down sides to this. The obvious one > is writing more code, where it might be generated from a model. The > other is that a tight coupling/merging of the FSM logic and the model > state would tend to lead to application models geared toward a single > FSM.
Mike, thanks for taking time and looking at my stuff. Yes, I decided that tight combination of application domain model with FSM is what needed for web application. I can try to explain my reasoning. I thought that for a web app (well, I guess any app) there are two kinds of inputs: * business data * command The command may be of two kinds: one is submit command, "apply this business data and then do whatever is needed". Another is navigation command, "give me that page/resorce" or "go from this page to that page". Business data is usually combined with submit command. Navigational commands are usually sent without accompanying data. But generally, we have two possible flows, two state systems: one is "view state", that is "go from this page to that page", and another is model state: "apply this data to the model, if appropirate in its current state". I tried to manage two state machines and decided that it is inconvenient. For example, if you go from page 1 to page 2, while submitting data, what do you do? First, you must see is it possible at all to apply data to the model in its current state. If not, where do you go? Will you stay on page 1, or you go to page 2, or you go to some error page? If you were able to apply data, how do you know, that page 2 is capable to display modified model data? I tried several synchronization schemes and they turned out to be too complex. So, I decided to use only one state machine. Obviously, I could not throw out application domain model, so I decided to base my FSM on it, and to forgo the whole idea of "view state". In my project there is no view state or some other pre-state or post-state, there is just one state. My project still uses states and it is FSM, but instead of defining isolated state transitions, I define only several "wizard states", and compute "yes" or "no" transitions based on current model standing. I think this allows to get rid of ambiguity. Yes, this requires to write some code, but not that much, and conceptually it is not that different than writing XML elements, but works faster and I don't need XML parser. The domain model itself lives its own life, and changes its state despite of wizards or any front ends. But, if I need to "wrap" the model with some kind of flow, I can query model, and change view state (ok, ok, I can say that wizard defines view states) according to main model state. So, in a sense, I still have two state machines, but view state machine is strictly dependent on domain model state machine. > If I were going for more re-usability I might like to have > multiple patterns of interaction that uses the same application model > objects. I think that each pattern can be defined as a separate wizard, but the domain model is still the same! Rules to update domain model did not change after another wizard was "wrapped" around it. I should put down more samples, maybe I can clear it up even for myself ;) > Have you considered combining an XML representation of the > state machine with something like EL expressions or XPath expressions > that perform the same logic in terms of the target model's state? I am not a big fan of XML, what is the point? Will it be more portable or will I be able to change XML definition without recompilation? Hardly. I think XML flow representation is a gimmick. XML is better than csv/property file when there is a need to represent hierarchical data. XML makes sense if it will be processed by XSL. But XML not a programming language. So, not now ;-) > Having used iLogic's Rhapsody to model and generate real time process > control systems, I think that a case should/could be made for automating > the mechanical structure of the FSM implementation and isolating it from > the user input (identification of states, transitions, triggers and > guards). The whole point of making Easy wizard as it is, is that I considered user input as inherent part of the process. There are many workflow solutions for more deterministic systems. In case of web app user makes the difference, and he also can go Back (dreaded Back button and double submit) or go to a particular URL of his liking, and this must be processed by FSM. So, it is not like FSM directs next state. SOmetimes FSM is queried "I want to go to THAT state" and then it must determine is it possible. It is kind of inverted FSM. > What are your thoughts on this? No particular thoughts right now, I am not even sure that I wrote anything legible in this email ;) > Which direction are you currently > moving in with your project? If you noticed, Easy Wizard consists of two separate modules: wizard definition, which does not require UI, and some kind of web/page manager. The one that exists now, works well, but I decided to integrate it into DispatchAction-kind of class, and to leverage the idea of two-phase input processing in a separate library, which I just rolled out: http://struts.sourceforge.net/strutsdialogs So, my plans is to create a WizardAction as part of other helper actions for Struts. Then... to revisit JSF integration, and to integrate in other frameworks, like Spring. So, nothing new conceptually right now. But I would be glad to hear new ideas ;) Mike. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
