<snip>
Now, part of my job is giving Cocoon presentations and trainings, so I also talk about flowscript, continuation trees, the end of back-button infamy, etc. I always have a low of wow's and people find this very interesting.
And then, there are two categories of people :
- those who have no existing background on page flow problems. They have no problems with our way of doing it.
- those who have some background, either as code or as trained people.
People in the second category, after the mind blow is finished, ask me :
- "why use JavaScript ? I'm used to plain Java and don't want JavaScript".
Well, let's work on a Brakes/Java based flow engine that supports continuations. We can also use the Eclipse Java compiler to behave as a Java interpreter (see ftp://ftp.primaryinterface.com/pub/javacAPI) so that you get all the development-time benefits of a scripting language and still use Java and get code-completion in your IDE. This seems to me like a much better solution for such people, than reverting to a FSM approach simply because they don't want to use JavaScript.
- "I have an existing backend" or "I use Struts". "How can I link it to the flow ?"
What should I say ? Use actions ? Use Struts as the toplevel servlet and Cocoon for the view (I did this once) ?
Well, I would say that it is very easy to convert a Struts app to use Flowscript. I originally converted the IBatis Petstore (http://www.ibatis.com), a Struts application, to the current Cocoon Petstore sample (with Velocity as the only view) in 1 day.
Is "StrutsFlowEngine" really a viable approach? If so, why not put the code in the scratchpad to demonstrate it.
Regards,
Chris
