Blogging Roller: Why am I doing this Control Flow stuff?

Why am I doing this Control Flow stuff?

Maybe I should explain why I'm wasting valuable late-night Roller development time with this continuations stuff. I'm experimenting with Control Flow because I'm frustrated with Struts (and other web-MVC frameworks) lack of support for building complex web applications where user-interactions extend over multiple pages. I'm tired of little ad-hoc tricks like session attibute here, request parameter there, breadcrumb stacks, and hidden fields that developers must remember to place on each page. There has got to be a better way and a continuations-based approach seems like it may be that better way. Ken McLeod explains the appeal of a continuations-based approach quite nicely:

<a href= "http://bitsko.slc.ut.us/blog/prevalent-continuations.html">Ken MacLeod: Continuation-based web frameworks let you write complex, modeless, interactive web applications in a top-down, linear fashion as simple as writing command-line based applications that prompt for input.

That sounds great, but I don't really want to switch to a new framework to take advantage of a continuations approach. I've got an investment in Struts and JSP and what I would really like to do is to learn from the continuations-based frameworks and, if possible, apply that knowledge to my existing webapps. What I would like to learn is:

Should you write entire webapps as "top-down, linear" programs, or should you just use a continuations-based approach for portions of webapps, perhaps only the parts that involve multi-page user-interactions. Charles Miller points out an important reason why you might not want to take the entire-app approach: webapps must be able to provide meaningful and bookmarkable URLs (cool URLs) and some continuations-based frameworks make this difficult.
Does it make sense to use Control Flow in the context of a plain-old web-MVC based framework (e.g. Struts, Webwork). How would you do this? Does the Control Flow script kick in before an Action is run, as part of the Front Controller, or after the Action completes?
Does it make sense to use Control Flow in the context of a next-generation web-MVC based framework with events and server-side UI components (e.g. JSF, Tapestry)? How would you do this? How should the Control Flow engine fit into the component request/response lifecycle?

There you have it. Please, leave a comment if you have any insight into any of the above questions.

Dave Johnson in Java • 🕒 02:59PM Mar 16, 2004

Tags: Java

Comments:

At Charles Miller's page you saw comments about RIFE. I could absolutely recommend it for a new project. Bookmarkable "elements" are written in Java (or in the simplest cases, in HTML with additional RIFE-specific directives interspersed). A certain amount of added complexity in (e.g.) HTML forms is more than compensated for by a data validation system that is integrated across bean-class instances, form data entry, and DB persistence.
These "elements" are tied together flow-wise by a sitemap written XML.
I can't comment tho on integration with something like JSF, or a pre-existing codebase in Struts, but parbly Geert will find this discussion and comment.

Posted by F.Baube on March 17, 2004 at 09:16 AM EST #

RIFE is an end-to-end framework where most parts are possible to seperate. There is not support for JSP though and the only currently supported view technology is specific to RIFE. As you said, it's a good choice for new projects, but I don't think it's appropriate for existing ones. The continuations engine seems to be extractable since someone did it and is using it for standalone applications. The nice integration of the continuations into the web application engine is quite RIFE specific though.

Posted by Geert Bevin on March 17, 2004 at 09:55 AM EST #

Dave, I don't think you've done a good job of outlining your requirements. As far as I can tell, the Action paradigm really is the best way to design large, complex web applications. The entire-app approach (or even the Cocoon Flowscript approach) just won't scale. It seems your problem is really about a lack of abstraction. I can't imagine it'd be really that difficult to solve. If you could somehow build into a Struts the concept of an ActionGroup which would be composed of many different Actions that shared the same ActionContext (secretly stored in the Session of course). I mean, this is all continuations do--they provide a persistent context for certain variables that persist beyond the request scope. Personally, I think instead of trying to hack continuations into Struts (which is impossible due to the way Java works) I would think more about solving the specific use cases you need to solve.

Posted by Buko on March 17, 2004 at 04:44 PM EST #

Buko: I agree that I need to "think more about solving the specific use cases" that I have and to add some abstraction so I can rise above the ad-hoc and error prone techniques I have been using. That is part of the reason for this exercise. I'm experimenting with Control Flow to see if there is anything I can learn that will help me come up with the missing abstraction. Perhaps Control Flow can be a part of that abstraction, I'm not sure.

Posted by Dave Johnson on March 17, 2004 at 05:22 PM EST #

I agree, flowscript in Struts would rock. I too have taken flowscript out of Cocoon and am actually using it in a webstart app I'm working on. I've started to try to adopt it to Struts, but haven't finished as I'm not sure how to handle Struts features like forms. While I originally saw use as the control flow, I know think flowscript would be best as a replacement for actions, specifically actions involved in a wizard. Even with flowscript, I still think Actions have a place, but more complex operations could easily be written as flowscript.

Posted by Don Brown on March 17, 2004 at 07:27 PM EST #

Yep I agree entirely with Don Brown. Control Flow Script is an ideal replacement for complex navigation. So we can now have actions just call business functions and just respond with a success or failure. The navigation , decision making on the next page etc, should all be Flow Script's responsibility. This will also clean up some Struts-Config.xml mess..

Posted by Steve Shelley on March 17, 2004 at 09:15 PM EST #

I don't like the fact that Cocoon's flow script uses javascript. Would it be possible to make that BSF compatible so that I can use jython, jruby or bean shell

Posted by Steve Shelley on March 17, 2004 at 09:22 PM EST #

Steve: ControlFlow uses a modified version of JavaScript that supports continuations. Are there any other Java-VM based languages that support continuations. Python and Ruby support continuations, but do Jython and JRuby? And what about Groovy, does it support continuations?

Posted by Dave Johnson on March 17, 2004 at 09:26 PM EST #

Groovy, Jython, and JRuby do not support continuations. Rhino and SISC Scheme are, AFAIK, the only choices.

Using continuations with the "next-gen" MVC frameworks (ie, clones of WebObjects circa 1996) is not only possible, but very desirable, and gets rid of the "scalability" issues that I assume Buko is talking about - you don't really have a single flow for the entire app, you have lots of event handlers each with independent flow. Done properly, this approach absolutely rocks. I'm a bit skeptical about grafting this onto an existing framework like Tapestry or Struts, however. Continuations are a game changer, and a lot of the existing infrastructure would suddenly be redundant or get in your way.

If you want to talk about doing it "right" (for my NSHO of what's "right"), contact me...

Posted by Avi Bryant on March 18, 2004 at 12:50 AM EST #

From what I read in the readme of the following page http://www.jython.org/README.txt, jython 2.2 will support generators. But I don't know if that alone would be enough to implement continuations.

Posted by Unknown on March 19, 2004 at 07:37 PM EST #