Can someone please explain to me what Borges does? Its home page
isn’t very descriptive, but I get the feeling that it’s extremely
neat.
- Bill Atkins
Hi Bill,
It’s some sort of framework that uses almost the same methods as seaside
(smalltalk).
IMHO it’s one of the best ways to code web applications.
On this site you will find a better documentation.
cheers,
Andreas
Bill Atkins wrote:
···
Can someone please explain to me what Borges does? Its home page
isn’t very descriptive, but I get the feeling that it’s extremely
neat.
- Bill Atkins
- Bill Atkins dejaspam@batkins.com [0534 01:34]:
Can someone please explain to me what Borges does? Its home page
isn’t very descriptive, but I get the feeling that it’s extremely
neat.
Follow the links to the SeaSide docs, they have pretty good explanation
of the principles.
All I’ve seen so far is either ‘look, we can do goto’ or
‘look, here’s Borges’, which is a learning curve so steep it starts to
look like a wall…
Few Borges specific links :
http://homepages.ihug.com.au/~naseby/42.html
Eric’s rubyconf stuff:
And there’s an Iowa (which is also continuation ish , and a cousin of SeaSide)
intro at:
[ I got the impression that Borges is still a little leaky, though I haven’t
had the cohones to try it out much yet ]
···
–
Did you know that if you took all the economists in the world and lined
them up end to end, they’d still point in the wrong direction?
Rasputin :: Jack of All Trades - Master of Nuns
It is nothing short of revolutionary. It feels a lot more like
writing a traditional GUI app than an Action based, Request and
Response app. I was just not able bring my self to write an app in
Seaside because of Squeak. Don’t get me wrong, Squeak is great, but I
have been wanting a Ruby port for some time.
Check out the SushiNet example, and start playing around with it. The
is the only way to understand how it differs from other web app
frameworks.
Cheers,
Wilkes
···
On Fri, 7 May 2004 09:33:57 +0900, Bill Atkins dejaspam@batkins.com wrote:
Can someone please explain to me what Borges does? Its home page
isn’t very descriptive, but I get the feeling that it’s extremely
neat.
- Bill Atkins
Dick Davies rasputnik@hellooperator.net writes:
I still can’t get my head round continuations - does anyone have a
good ref?All I’ve seen so far is either ‘look, we can do goto’ or ‘look,
here’s Borges’, which is a learning curve so steep it starts to look
like a wall…
I found reading (and understanding) this page:
http://pragprog.com/pragdave/Tech/Random/StackContext.rdoc
helped quite a bit. Specifically, the final implementation by Avi
Bryant which uses callcc should help.
···
–
Josh Huber
Iowa doesn’t use continuations. It takes the everything-is-an-object
approach and operates under a traditional request/response cycle. It
features seperation of content from code. Content is plain old HTML with
some simple markup additions for controlling the dynamic parts, and code is
just plain old Ruby. It can be used for full on applications as well as
simple dynamic pages as I have created an extension to it that lets one map
URLs to specific content objects.
I’ve finally gotten a start to the tutorial for it up:
http://enigo.com/projects/iowa
That whole site is actually implemented under Iowa, BTW.
There’s also a rubyforge project for it:
http://rubyforge.com/projects/iowa
Kirk Haines
···
On Fri, 7 May 2004 19:58:29 +0900, Dick Davies wrote
And there’s an Iowa (which is also continuation ish , and a cousin
of SeaSide) intro at:
Dick Davies wrote:
I still can't get my head round continuations - does anyone have a
good ref?
All I’ve seen so far is either ‘look, we can do goto’ or
‘look, here’s Borges’, which is a learning curve so steep it starts to
look like a wall…
I did a quick google search and came up with this mailing list thread:
http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg00499.html
It has the advantage of having a lot of people trying to explain it a
lot of ways, so hopefully one of them will start to make sense to you. 
The explanation that has always worked for me is that a continuation
remembers a point in the execution of your program. As long as you are
holding onto that continuation you can, at any point (and as many times
as you like), jump back to exactly that place in your program again.
It’s like a bookmark. You just replace your current execution context
with the one you copied for the continuation and carry on executing.
call/cc is a mechanism of getting/using the continuations which passed a
continuation into the method (or block, depending on implementation) you
ask it to call. The continuation it gives you is a capture of the point
in the execution just before the call/cc method call returns. So by
using that continuation, you can return from the method call over and
over as many times as you like.
We use this in seaside (and borges does the same) to allow the user to
use the back button in the browser. No matter how many times the user
goes back and clicks a link on the same page, the handling will always
be done by the exact same execution context. It doesn’t know it’s being
called over and over; it just knows it’s supposed to handle the clicks
generated from that page and it always does.
Hope that helps,
···
–
Julian
Beta4 Productions
Not a tutorial or reference, but here’s a stripped down
continuation-based web app that I wrote in order to demonstrate the
continuations “trick” from Seaside. It’s stupidly simplistic, which
makes me think it might help you a little.
http://chadfowler.com/lazyseaside/pm_seaside.html
Ignore the wrap_methods and “hints” stuff. That’s part of another
topic (http://chadfowler.com/index.cgi/Computing/Programming/Ruby/TypeWatching.rdoc,v)
Chad
···
On Fri, 7 May 2004 19:58:29 +0900, Dick Davies rasputnik@hellooperator.net wrote:
I still can't get my head round continuations - does anyone have a good ref?All I’ve seen so far is either ‘look, we can do goto’ or
‘look, here’s Borges’, which is a learning curve so steep it starts to
look like a wall…
We use this in seaside (and borges does the same) to allow the user to
use the back button in the browser. No matter how many times the user
goes back and clicks a link on the same page, the handling will always
be done by the exact same execution context. It doesn’t know it’s being
called over and over; it just knows it’s supposed to handle the clicks
generated from that page and it always does.
Is that always good? What if it means the users ends up clicking on the
purchase button twice and we charge their card twice? I’ve always
thought that it was best not to let the user use the back button in
cases like these (i.e., forward them to the right page, display an error
indicating that the posted values are stale, or something like that).
Carl
Julian Fitzell wrote:
Dick Davies wrote:
I still can't get my head round continuations - does anyone have a good ref?
I found this link very useful:
http://www.eleves.ens.fr:8080/home/madore/computers/callcc.html
Gennady.
- Kirk Haines khaines@enigo.com [0526 15:26]:
And there’s an Iowa (which is also continuation ish , and a cousin
of SeaSide) intro at:Iowa doesn’t use continuations.
Sorry, it’s so closely tied up in my head with Borges I assumed it was
a similarly implemented framework.
I’ve finally gotten a start to the tutorial for it up:
Cheers, I had the site bookmarked but I was waiting for a handhold…
Thanks for all the continuation links people have posted too, non-Smalltalkers
like myself appreciate it.
···
On Fri, 7 May 2004 19:58:29 +0900, Dick Davies wrote
–
It is easier to change the specification to fit the program than vice versa.
Rasputin :: Jack of All Trades - Master of Nuns
Carl Youngblood wrote:
We use this in seaside (and borges does the same) to allow the user to
use the back button in the browser. No matter how many times the user
goes back and clicks a link on the same page, the handling will always
be done by the exact same execution context. It doesn’t know it’s being
called over and over; it just knows it’s supposed to handle the clicks
generated from that page and it always does.Is that always good? What if it means the users ends up clicking on the
purchase button twice and we charge their card twice? I’ve always
thought that it was best not to let the user use the back button in
cases like these (i.e., forward them to the right page, display an error
indicating that the posted values are stale, or something like that).
No, it’s not always good. But it’s always good to be able to. Seaside
(and I believe Borges for Ruby implements this piece too) has a concept
of transactions or isolate blocks. The way this works is that you
execute a section of code inside a block. When that block terminates,
all the pages in that session get expired. So in the case of a shopping
cart, you would likely start an isolate block when they begin the
payment process and expire all those pages as soon as they press “Purchase”.
Note that you also have control over which pieces of state get
backtracked with the back button. So you can have the UI state
representing, for example, which tab is selected roll back with the back
button, but leave your model data (such as the shopping cart contents,
perhaps) so it always represents the newest data. It requires some
thought in each case to determine what the desired semantics are, but
once you decide what you want it’s easy to implement either way.
Julian
Carl Youngblood wrote:
Is that always good? What if it means the users ends up clicking on the
purchase button twice and we charge their card twice? I’ve always
thought that it was best not to let the user use the back button in
cases like these (i.e., forward them to the right page, display an error
indicating that the posted values are stale, or something like that).
Well, this is actually a problem that has been given some thought. And
thus not a problem. In Borges, you would wrap the sequence of your
checkout steps with:
session.isolate do
show_checkout_step_1
show_checkout_step_2
# etc…
end
The effect of this is that you get a UI Transaction that protects your
checkout steps. Once the user enters the transaction, he can ‘back’ and
‘forth’ at will withhin the transaction. But once the final button for
checkout is hit, the transaction will be closed and the user can’t go
back - all he gets is a redirection to the current page of the application.
I think that declaring the back button as forbidden is a bad idea,
rather make it work the way we expect it to !
There is also a
session.once do
show_some_unique_timedependent_info
show_some_other_stuff
end
that permits to step trough the sequence just once. You might want to
download and install Borges and run the following script on your machine
for happy testing of these features (and uh admire the nice
implementation we have 
)
require ‘Borges’
require ‘Borges/Test’
require ‘Borges/WEBrick’
Borges::WEBrickServlet.start
Then make a connection to localhost:7000/borges/test. I am talking about
~ the Once and the Transaction tab (whoa check out the tab control while
your at it).
The documentation at www.tua.ch/ruby is rather bad I fear; I will
hopefully get to write a full introduction that also explains the
concepts a bit more in depth.
kaspar
semantics & semiotics
code manufacture
www.tua.ch/ruby
Drop me an email if you have any questions. More is going up later this
evening.
Thanks,
Kirk Haines
···
On Sat, 8 May 2004 05:56:09 +0900, Dick Davies wrote
I’ve finally gotten a start to the tutorial for it up:
Cheers, I had the site bookmarked but I was waiting for a handhold…
I thought I’d run down a quick list of Iowa/Borges differences.
-
Iowa operates on a traditional request/response paradigm and represents
everything as an object, using objects to track state; Borges uses
continuations to maintain the user’s path through the application. -
Seaside (and thus, Borges, too) has some fancy neat stuff in it that I
would like to implement in Iowa, like the notion of isolating a section of
the application so that when the user exits that section, the past pages are
expired. Seaside/Borges definitely has some advanced features that Iowa
does not have. -
Borges is targetted very specifically at web applications. Iowa was also
targetted specifically at web applications, but I have built a layer that
allows one to map URLs to specific components to handle them, allowing Iowa
to be used as a general engine for dynamic web content and allowing more
flexibility about how entry points into an application are mapped to URLs. -
Borges and Iowa both run as discrete backend processes from the webserver.
-
Iowa uses a template type architecture using plain HTML. Borges generates
the HTML programatically using an API to describe the content and a renderer
to take that description and turn it into appropriate content (which means
that the same Borges application could, in theory, generate HTML or run from
command line or generate a Fox GUI). -
Iowa has full access to the HTTP headers that are received and that are to
be sent back to the browser, making it easy to use cookies, set content
types, and that sort of thing, where needed. I don’t know about
Borges/Seaside on this one? -
They are both pretty neat, even though they really have more differences
than similarities. Borges definitely pushes the innovation envelope more
than Iowa does. Iowa is more conventional.
There are a lot of other things that are different about them, despite a few
superficial similarities, but that should paint a good general picture, I
think.
Kirk Haines
···
On Sat, 8 May 2004 05:56:09 +0900, Dick Davies wrote
Iowa doesn’t use continuations.
Sorry, it’s so closely tied up in my head with Borges I assumed it
was a similarly implemented framework.
Kaspar Schiess wrote:
The documentation at www.tua.ch/ruby is rather bad I fear; I will
hopefully get to write a full introduction that also explains the
concepts a bit more in depth.
Borges sounds pretty cool. Better documentation (including a good
tutorial) would be a great help. A couple quick questions:
- Can it work with mod_fastcgi/ruby?
- Does the sessioning stuff support automatic fallback to GET-based
session ID propagation if the user has disabled cookies? - Can sessions be stored in a database or a drb store so that web
traffic can be easily load-balanced across multiple web servers? - Is it necessary to construct HTML pages programatically or can you
have simple unbroken HTML templates that are editable by a
non-tech-savvy graphic designer?
Carl
Now THAT is a cool idea. I need to think about how to steal that and
implement it in Iowa to selectively expire pages from the page cache. That
would be a useful capability.
Kirk Haines
···
On Sat, 8 May 2004 05:33:02 +0900, Julian Fitzell wrote
Seaside
(and I believe Borges for Ruby implements this piece too) has a
concept of transactions or isolate blocks. The way this works is
that you execute a section of code inside a block. When that block
terminates, all the pages in that session get expired. So in the
case of a shopping cart, you would likely start an isolate block
when they begin the payment process and expire all those pages as
soon as they press “Purchase”.
Kirk Haines wrote:
- Iowa uses a template type architecture using plain HTML. Borges generates
the HTML programatically using an API to describe the content and a renderer
to take that description and turn it into appropriate content (which means
that the same Borges application could, in theory, generate HTML or run from
command line or generate a Fox GUI).
This is only because we haven’t implemented a templating layer in
Seaside. There is a templeting system called Nori written by Colin
Putney for Seaside, so it can be done.
- Iowa has full access to the HTTP headers that are received and that are to
be sent back to the browser, making it easy to use cookies, set content
types, and that sort of thing, where needed. I don’t know about
Borges/Seaside on this one?
Seaside does as well. We don’t pass the server’s request object in
directly because we want an abstraction there, but we do have a request
object that is accessible.
- They are both pretty neat, even though they really have more differences
than similarities. Borges definitely pushes the innovation envelope more
than Iowa does. Iowa is more conventional.
I don’t know about conventional. But Seaside is the successor to
Iowa, so it’s hardly surprising that Seaside pushes the envelope more.
Iowa doesn’t use continuations.
Sorry, it’s so closely tied up in my head with Borges I assumed it
was a similarly implemented framework.
Iowa is Borges’ grandparent.
I thought I’d run down a quick list of Iowa/Borges differences.
Seaside (and thus, Borges, too) has some fancy neat stuff in it that
I would like to implement in Iowa, like the notion of isolating a
section of the application so that when the user exits that section,
the past pages are expired. Seaside/Borges definitely has some
advanced features that Iowa does not have.Borges is targetted very specifically at web applications. Iowa was
also targetted specifically at web applications, but I have built a
layer that allows one to map URLs to specific components to handle
them, allowing Iowa to be used as a general engine for dynamic web
content and allowing more flexibility about how entry points into an
application are mapped to URLs.
Borges can use specialized handlers for particular types of content, for
example, CSS is generated from the CSS definitions for all the visible
components. These do not have “pretty” URLs, but handlers for just
about anything could be easily created. One of the posters to the
borges-users list is using a handler to generate SVG on the fly.
Borges and Iowa both run as discrete backend processes from the
webserver.Iowa uses a template type architecture using plain HTML. Borges
generates the HTML programatically using an API to describe the
content and a renderer to take that description and turn it into
appropriate content (which means that the same Borges application
could, in theory, generate HTML or run from command line or generate a
Fox GUI).
As Julian also said, a template system could be plugged into Borges very
easily.
- Iowa has full access to the HTTP headers that are received and that
are to be sent back to the browser, making it easy to use cookies, set
content types, and that sort of thing, where needed. I don’t know
about Borges/Seaside on this one?
The response headers can be set fairly easily, request headers are
semi-available.
- They are both pretty neat, even though they really have more
differences than similarities. Borges definitely pushes the
innovation envelope more than Iowa does. Iowa is more conventional.
So far, Borges is on par with Seaside 2.3 for the purposes of evaluating
innovation.
···
Kirk Haines (khaines@enigo.com) wrote:
On Sat, 8 May 2004 05:56:09 +0900, Dick Davies wrote
There are a lot of other things that are different about them, despite
a few superficial similarities, but that should paint a good general
picture, I think.
–
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
A couple of quick answers :
Carl Youngblood wrote:
Borges sounds pretty cool. Better documentation (including a good
tutorial) would be a great help. A couple quick questions:
- Can it work with mod_fastcgi/ruby?
I have a working version with mod_ruby. This is not in the CVS and will
stay around for another two weeks on my HD; I am definitily wanting to
do a fastcgi port. Current Integration methods are:
- mod_ruby (experimental)
- cgi
- webrick
- Does the sessioning stuff support automatic fallback to GET-based
session ID propagation if the user has disabled cookies?
You must use URL based session id's, there is no way around it. You can
optionally have cookies on top of that, but the urls really must be
there because of how Borges/Seaside is designed. And this probably does
not bother you anyway, since Borges should only be used for
Applications, not for Web Publishing.
- Can sessions be stored in a database or a drb store so that web
traffic can be easily load-balanced across multiple web servers?
One session should always use one server. This is because server state
is not saved, but kept alive in a Ruby process on the server. Ruby can’t
currently dump what would be neccessary to dump to be able to save off
to a database (mainly continuations…).
Load balancing can balance sessions (users) to different backends, from
different frontends. But one session is always handled by one and the
same backend.
- Is it necessary to construct HTML pages programatically or can you
have simple unbroken HTML templates that are editable by a
non-tech-savvy graphic designer?
I am using eruby to do my templating, so no trouble there. You just
need to take special care when constructing forms.
May I suggest that we take this discussion to the borges-users list ?
And could you sign here, here and here with your blood please ?
Tell me if you need a better answer, I will keep a list of things to put
in the introduction based on this conversation.
kaspar
semantics & semiotics
code manufacture
www.tua.ch/ruby