From: Kirk Haines <khaines@...>
Date: 2004-05-08T21:27:20+09:00
Subject: Re: What is Borges?

On Sat, 8 May 2004 13:19:37 +0900, Carl Youngblood wrote

> That's what I've been told.  Supposedly Borges is for application 
> development so users shouldn't be bookmarking URLs, since they 
> reflect a particular state of the program and not a place where 
> content is located.  I disagree with this compartmentalization,
>  since I can envision plenty of content-based web sites that use 
> authentication.  Please correct me if I'm wrong here, Borges people.

If you have an application that a mutual fund company uses to enter 
performance information about their funds for their web site, creating a 
bookmark in the middle of that application isn't going to be useful as the 
content at that time is inherently transitional.  The user is in the middle 
of doing something, and when that something is done, that prior state is no 
longer relevant.  So, one can bookmark the entry point into the application, 
but bookmarks while working in the application are going to be ugly URLs 
that are only relevant for a limited period of time.  This is the kind of 
application that the Borges model works well for.

The places where the model gets difficult are for sites that have sections 
that are application-like, but have other areas that are not.  A job search 
site, for example, fits this.  You have several areas that are small 
applications in a job search site, from entering information to searching 
it. while holding onto some session data such as your login id.  However, 
when you find a piece of information that is of interest, you want to be 
able to bookmark it and be able to come back to the same piece of data an 
hour, a day, or a week later.

If you want to do the whole site in Borges, instead of choosing to write 
just the inherently transitional application areas like the data entry areas 
in Borges, and the other end-data areas in something else, it may be 
difficult (though, I think, possible, if someone really wanted to do it).

At one point I ran into this very problem with Iowa at one point.  I was 
taking over a large site that had been implemented in ASP.  I, however, was 
getting none of the ASP that actually implemented the site, and one of the 
site's features is that most of its URLs have 2 different pieces of content, 
depending on whether one is logged into the site or not (and a login gets 
tracked with a cookie).  Additionally, there are areas interspersed through 
the site where one gets into application-like interfaces, with data entry or 
with pages getting a lot of data from a database.  So I needed to be able to 
do a whole site dynamically in the sense that login information has to be 
checked for every page load, and one of two content pieces delivered 
depending on that login information.  Additionally, in some cases those 
content pieces had to themselves be dynamic and application-like.  And 
nearly every URL has to be a clean looking, bookmarkable URL.

I looked at 6 or 7 different ways of doing this, but I really wanted to be 
able to implement the entire site under the same framework for simplicity's 
sake, and I really liked how easy it was to build dynamic content displays 
under Iowa.  In the end I built a relatively simple mapping layer to map 
URLs to specific components.  Voila!  All the ease and simplicity of Iowa 
templating and dynamic content generation; I could do the whole site under 
it, using its features where I needed them and just using plain HTML files 
for the static content areas where I didn't.

Ah, baby is crying, so I'll quit rambing and go soothe a little girl, now.


Kirk Haines