This post originated from an RSS feed registered with Ruby Buzz by David Naseby. Original Post: Inside Borges, Part the Third Feed Title: naseby + ruby + stuff Feed URL: http://homepages.ihug.com.au/~naseby/rss.xml Feed Description: Random wanderings through Ruby. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by David Naseby Latest Posts From naseby + ruby + stuff

Enough digression. Its time to get back into it, and see what happens within Borges::Session. I’m getting a little keen to do some real work with Borges rather than just spelunking, so I need to squeeze the rest of this series out in a hurry while the motivation is up.

Borges::Session, at its core, works like Poor Man’s Seaside, with the continuations (one main flow continuation, one continuation for each set of controls (page)) contained as instance variables rather than globals. Compare #respond with ContinuationServlet#ask. Just inline a bunch of functions and remove a bunch of flexibility, and its the same code. answer is the same thing as request, and Borges allows filters to modify the request before returning it. #return_response wraps a call like $cc.call.

Filters are instances of Borges::Filter, meaning really that they define the method #handle_request_in. They are registered with Borges::Session#add_filter, and removed with #remove_filter. The filters included in the library, which give pretty good examples of their use, are Borges::BasicAuthentication, Borges::Once, and Borges::Transaction.

So where did all this leave us? Unwinding continuations back to Borges::RedirectResponse.new, if I haven’t lost track. So the path of Request to Response has led us out of Borges::Session, at last. RedirectResponse is a subclass of Borges::Response, and it is named pretty obviously – it redirects the response. This is another one of Borges’ little tricks: after processing a page, it redirects to itself. This kind of behviour prevents a user refreshing and getting a resubmit warning from the browser, on post-heavy web apps. Its a technique I’ve used before to create a “one-page-thin” app – one url, every action submits a post, the page is processed and shoved into a session, then the page redirects back to itself and serves up the cached image of the page. Because Borges muddies the querystring with Session and user keys, each page will look different to a browser. This allows the use of the Back button. This in turn, is probably the major technical reason why the querystring MUST be used for Session and user keys in Borges, instead of the more sanitary (REST-style) post or (bleh) cookie methods.

I’m going to read that paragraph again after I publish this, and cringe. I apologise to my reader(s).

I’m not entirely sure where I am anymore, but I think I’ve gone close to bringing the response all the way out to the browser, from the continuation return in @Borges::Session#enter_session. Part the fourth will look at how the html is formed, and probably (hopefully) clear up bits I’ve missed from here.