Cleanly defining and managing the flow of screens in web applications, particularly multi-step processes or workflows can be challenging. Due to the stateless nature of HTTP, state has to be managed through cookies, hidden fields, URLs or session data held on the server. What if the user clicks the back button? Meh.

I was thinking, why can't we model web application flow like the monolithic programs we knocked together when we were young? (Or was that just me?)

10 PRINT "What is your name?"
20 INPUT NAME$
30 PRINT "Hello, ";NAME$
RUN

What is your name?
? Alex
Hello, Alex

It turns out I hadn't invented anything. An approach known as a continuation can make this happen. The Apache Cocoon and Seaside framework do just this in a web setting and this article from IBM describes it very well. A continuation is effectively a way of freezing code execution mid flow and squirreling it away to be continued later. When that happens, all prior state/variables are as they were and the code can continue to run, unaware that anything happened.

Somewhat like hibernating your laptop, rather than shutting it down, perhaps.

As it happens, this approach fits well with the HTTP request/response cycle. Code runs, needs more input - continuation stored and HTML form displayed. User supplies more input and clicks submit. Server runs continuation and does some processing - decides more data is needed, continuation stored and another HTML form displayed.

I imagine this kind of monolithic flow would make for very readable business process implementation. I like the idea of the logic of a process is defined as simply as possible in a single location, not scattered across user controls and databases.

One to ponder. This could be one of those cases where a disproportionate amount of complexity is introduced to make something else simpler. Maybe the way we program for the web isn't perfect, but isn't horribly broken either.