<skipped> > I think the finite state machine approach is difficult to extend to > complex sites. It is very difficult, and rather limiting, at least for > me as a programmer, to think the application as a finite state machine > only. Any time I need to introduce a new state in my application, I > have to reconsider all the transitions to that state, and the impact > it has on the existing system.
Yes, that's true. It's quite difficult to support large sites with a state-machine like descriptions, but for web apps that are using a lot of forms and have a little publishing this approach can be very useful to control user actions. We are using something like this to describe the flow of application: <flow> <state id="first"> <on-enter> <exec operation="OnEnterOperation"> <param name="user" value="$currentUser" /> </exec> </on-enter> <on-event name="insert"> <exec operation="ValidateInsert"> <param name="input" value="$userInput" /> <result id="isValid" /> </exec> <if test="$isValid"> <exec operation="PerformInsert" /> <goto state="second" /> </if> </on-event> <on-exit> <!-- Perform on exit operations --> </on-exit> </state> </flow> The handler of this is implemented as a Session Bean and can be used from whatever application you like be it based on Struts, Cocoon or something else using special flow controll actions. In our application, the user can have multiple started flows and can switch between flows (either implicitly or explicitly), e.g.: the system operator can start multiple registration flows and work with them independently, even using multiple browser windows. The Struts/Cocoon actions just translate requests to events + data and call flow controller to perform the logic. Controller returns the current state and processing is forwarded to the handler of the current state, e.g. another pipeline that displays the current page. > > I'd be more happy if I can describe the flow in a "normal" programming > language, where I can express complex flow by writing a program. This > is what I'm trying to do in the Schecoon sub-project. Using the Scheme > language, and the fact that continuations are first class objects in > it, I want to implement the ideas described in the resources I > mentioned earlier. But the language to describe the flow will not be > Scheme, but one with a more familiar syntax. Maybe Java? ;) Why not use EJB (Session Beans) or something similar to them (e.g. custom Avalon components) to control the flow? You can implement *anything* you want in Java. The reason that we don't use Session Beans as-is, is that it would have a lot of similar code. Our flow syntax is quite simple, but powerful and it's possible to describe most of the flow logic with it (the rest can be processed using custom operations that are implemented in pure Java). And another goog thing is that the flow language is XML and thus a visual editor can be written quite easily. I've been also thinking about adding extension mechanism (something like transformers/logicsheets) that would allow to add custom handlers to our flow script and an idea came to me: maybe flow controll can be plugged to Cocoon using sitemap logicsheets? In that case nothing is changed in Cocoon core and everybody can have the flow controller he needs/likes. Just my <i18n:currency value="0.02" /> Regards, Konstantin Piroumian > > Best regards, > -- > Ovidiu Predescu <[EMAIL PROTECTED]> > http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]