This post originated from an RSS feed registered with Ruby Buzz by Michael Neumann. Original Post: Serialization, Continations and Blocks Feed Title: Mike's Weblog Feed URL: http://www.ntecs.de/blog-old/index.rss?cat=ruby&count=7 Feed Description: Blogging about Ruby and other interesting stuff. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Michael Neumann Latest Posts From Mike's Weblog

Blocks

In the rendering-phase, you usually define some actions and input elements. This is currently done this way:

  def inc; @cnt += 1 end
  def dec; @cnt -= 1 end

  def render_content_on(r)
    r.anchor.action(:inc).with('++')
    r.anchor.action(:dec).with('--')
  end

While with blocks, you can write:

  def render_content_on(r)
    r.anchor.action { @cnt += 1 }.with('++')
    r.anchor.action { @cnt -= 1 }.with('--')
  end

When it comes to storing a session on disk, we simply mark those pages for which a block handler was specified, as "needing another render-pass before being able to respond to an action". So, in the rare case of needing to shutdown the computer, we don't loose any information. It's just that the user has to reload the page.

Continuations

We can rebuild block handlers, by executing their definition (render-phase). But that does not apply to continations. If you serialize a session with active continuations, Wee will replace the continations with marker objects, so that we can later detect that there was an active contination going on. If this happens, Wee will notify the user about this situation and will return to the calling component and call it's method fallback_from_cc. If you want, you can still use old-style call behaviour by passing the name of the return method. Then you won't loose any information.

Another idea is to use DragonFly's checkpointing support. This would be a 100% solution for the whole problem.