Shibboleth Developers

[Tom Scavo <>]

On Tue, 2 Nov 2004 11:33:54 -0500, 

<>
 wrote:
> I recently saw this entry on Jon Udell's blog, describing how gmail
> has been programmed.... I was wondering whether anyone has any
> experience with this approach, and whether it might be at all
> relevant to the proposed SHARPE GUI for maintaining ARPs?

I think the bottom line is: you can apply this technology to ShARPE,
and the application will almost certainly perform better as a result,
but it may not be worth the extra effort in this case.

The technology here is client-side JavaScript, specifically the
XMLHttpRequest object:

http://jibbering.com/2002/4/httprequest.html
http://developer.apple.com/internet/webcontent/xmlhttpreq.html
http://xmlrpccom.sourceforge.net/scriptserver/scriptserver/docs/scriptserverse2.html

I've been using and teaching JavaScript for eight years but I hadn't
heard about XMLHttpRequest until yesterday.  It's cool.  Essentially,
JavaScript can make arbitrary HTTP requests just like J2EE and other
server-side technologies.  You load some JavaScript code (an "engine")
into a hidden frame, which handles UI events in the content frame. 
When necessary, the engine requests some server-side component that
updates the application state and/or returns some data.  The engine
interprets the data and updates the UI in the content frame.  Any UI
elements that can be manipulated by JavaScript may be handled in this
way.

For example, suppose the content frame contained an HTML SELECT
element where the user selects and removes an option (by pressing a
button).  Typically, the form POSTs a request to a controller on the
server, which updates the application state with a new option list
(minus the removed option) and then returns an updated HTML page.  
This works well, especially if the next page is some altogether new page.

An alternative approach is to define an onclick handler for the button
that issues a similar request to the controller using XMLHttpRequest.  
The controller updates the application state as it did before but this
time it need not return any HTML in the body of the respnse since the 
JavaScript engine, upon receiving the response, simply rebuilds the 
option list on the fly (which is something JavaScript does quit well).

So, if you have a UI that can be manipulated by JavaScript and if that
UI doesn't need to change very much as a result of a particular user
interaction, then the alternative approach is a potential big win.  This 
approach works well with Gmail since the content window is relatively 
static.

So what about ShARPE?  A potential application is the transition from
screen 2A, a list of federations, to screen 2B, the same list with one
of the federations expanded:

Screen 2A:
+ EBSCO
+ EDINA
+ Elsevier
+ JSTOR

Screen 2B:
+ EBSCO
+ EDINA
- Elsevier
 - Biotechnobase
 - Embase
 - Neuroscion
+ JSTOR

As a result of clicking "Elsevier" on screen 2A, the services expand
on screen 2B.  Everything else on the screen remains the same, so this
is a potential application of the technology.  However, manipulating
an unordered list (UL) with JavaScript is not as easy as manipulating
a SELECT element.  The latter works on all browsers, but modifying
arbitrary page content (like lists) is not something all browsers do
in the same way, and some not at all.  So now we have to do browser
checking, which is somewhere I'd rather not go.  I'd much rather spend
my time on the server than on the client struggling with cross-browser
issues.

Conclusion: If the user interface is primarily HTML form elements
(which JavaScript has been able to manipulate since the beginning),
then XMLHttpRequest is a distinct possibility.  Otherwise you have to
consider your users and their browser of choice, and weigh this
against the potential benefit of using a non-standard technology. 
Gmail chose the latter, and it was the right choice given the type of
application it is and the efficiency requirements it demands.  I'm not
sure ShARPE is in the same category of application, however.

Hope this helps,
Tom