Marc Bowes's Profile

You want to be careful rescuing Exception as it catches things like Ctrl-C and other signals. This is because For example:

$ ruby -e "begin; sleep(9999); rescue Exception => e; puts 'ignoring ' + e.class.name; retry; end"

Try pressing Ctrl-C or killing the PID. It really sucks having to kill -9 because the killer never knows if they're causing some sort of state corruption.

I recommend rescuing from StandardError and possibly Timeout::Error if you are hitting some external service. Another option is to do something like this:

begin
  #  ...
rescue SignalException
  raise
rescue Exception => e
  # as before
end

For those wanting to use this with Rails 3:

• Add the git link to your Gemfile [1]
• Make sure you use <%= when using the calendar_for helper

[1] gem "table_builder", :git => "git://github.com/p8/table_builder.git" - do not rely on the released gem, it seems to be stale.

I agree. 'Stretch', but cool at the same time.

This technique buys you two things:

1. You can support clients without Javascript (else you can just have the client do all the rendering and skip the Ruby-JS bridge entirely).
2. You don't have to duplicate code between languages.

However, the bridge is completely closed because JS runtimes are not equivalent. For example, how do you deal with timezones (you're making a new Date which means you can have some weird ordering issues if the day is different depending on whether the server/client are in a different zone.

Really cool though :-)

Thanks. Interesting cast.

Personally, I'd go one step further and completely ditch the initial rendering of the page. Then you can do all the rendering on the client side. The nice thing about that is you don't need to do the dual-nature templates. You drop support for clients without Javascript, but depending on your site, this may be OK.