Continuation and multiple forms in a page

[ngocdaothanh]

I'm very interested in continuation feature of Scala after playing
with this sample:
http://stackoverflow.com/questions/6062003/event-listeners-with-scala-continuations

I'm writing this web framework, thus I'm thinking of adding
continuation feature to it:
https://github.com/ngocdaothanh/xitrum

As I understand, continuation makes it natural to write program in the
serial style, like this:

val model = ...
val input = renderFormAndWaitForInput(model)
processInput(input)

Continuation is perfect if I only have 1 form in a page. But what if I
have 2 forms, say login form and register form, in a same page? The
user can submit any of the 2 forms. How should continuation be used in
this case? Do I have to combine the 2 forms into a single model and
wait for a single input? If I have to do that, it's not natural any
more.

Thanks,
Ngoc

[Chas]

I, too, am interested in this. Is there a role for continuations in
the request-response cycle? How would one use them? I know that
Seaside used them extensively, but don't remember seeing them in any
Scala web framework. But then, they've only been added to Scala
recently.

Chas.

On Dec 28, 8:59 am, ngocdaothanh <ngocdaoth...@gmail.com> wrote:
> I'm very interested in continuation feature of Scala after playing

> with this sample:http://stackoverflow.com/questions/6062003/event-listeners-with-scala...

[Derek Williams]

On Wed, Dec 28, 2011 at 4:59 AM, ngocdaothanh <ngocda...@gmail.com> wrote:

Continuation is perfect if I only have 1 form in a page. But what if I
have 2 forms, say login form and register form, in a same page? The
user can submit any of the 2 forms. How should continuation be used in
this case? Do I have to combine the 2 forms into a single model and
wait for a single input? If I have to do that, it's not natural any
more.

Probably best to create a reset block for each form. Something like this for a login page:

form {

  val username = textInput("Username")

  val password = textInput("Password")

  submit("Login")

  processLogin(username, password)

}

form {

  submit("Register new user")

  processRegister()

}

form would be your reset method, textInput and submit would be shift methods.

--

Derek Williams

[James Douglas]

> Is there a role for continuations in the request-response cycle?

I think so. Especially in situations where you have some known
workflow to process with multiple request/response cycles. Consider
the check-out process on an online shopping website, which requires
you to submit identifying information, then payment information,
approve your own order, and receive an invoice/summary. Each of these
depends on your state in the overall workflow, and can lead to some
nasty logic to determine what this is.

One way delimited continuations can be used to approach this is to
allow the workflow to be written in an imperative style, and
transparently convert each step in the workflow to a request/response
cycle. I wrote an example of this here:
http://www.earldouglas.com/continuation-based-web-workflows-part-two/

There's also a role for continuations on the server-side (e.g. Jetty
Continuations or Servlet 3 suspendable requests) to prevent
unnecessary blocking of your Web endpoints. Here's a little example:
http://www.earldouglas.com/asynchronous-network-io-with-scala-continuations/

[James Douglas]

I took a stab at integrating the example into Xitrum, and opened a
couple of pull requests for Xitrum and Xitrum-Quickstart:

https://github.com/ngocdaothanh/xitrum/pull/57

https://github.com/ngocdaothanh/xitrum-quickstart/pull/1

The example comes from https://github.com/JamesEarlDouglas/imperatively

On Dec 28, 9:29 am, James Douglas <jamesdoug...@gmail.com> wrote:
> > Is there a role for continuations in the request-response cycle?
>
> I think so.  Especially in situations where you have some known
> workflow to process with multiple request/response cycles.  Consider
> the check-out process on an online shopping website, which requires
> you to submit identifying information, then payment information,
> approve your own order, and receive an invoice/summary.  Each of these
> depends on your state in the overall workflow, and can lead to some
> nasty logic to determine what this is.
>
> One way delimited continuations can be used to approach this is to
> allow the workflow to be written in an imperative style, and
> transparently convert each step in the workflow to a request/response
> cycle.  I wrote an example of this here:http://www.earldouglas.com/continuation-based-web-workflows-part-two/
>
> There's also a role for continuations on the server-side (e.g. Jetty
> Continuations or Servlet 3 suspendable requests) to prevent

> unnecessary blocking of your Web endpoints.  Here's a little example:http://www.earldouglas.com/asynchronous-network-io-with-scala-continu...

[ngocdaothanh]

> I took a stab at integrating the example into Xitrum, and opened a
> couple of pull requests for Xitrum and Xitrum-Quickstart

Thanks, I've pulled them all.