[OPEN-ILS-DEV] ***SPAM*** Rethinking the Evergreen OPAC client

[steven chan]

Subject: Rethinking the Evergreen OPAC client

What has been the experience of people on this list on making changes  
to the opac and staff clients? Are there others on this list  who have  
thought about making the opac client a bit more modular and  
extensible, or who have tried redoing it using different coding  
techniques?

I want to briefly report on an ongoing effort of ours to try to recode  
the opac client:

1. Javascript libraries. In our effort, in which I am currently joined  
by a couple of youth interns and a couple of volunteers, we explore  
using the jQuery javascript library, see what coding patterns arise,  
and then follow them to their logical conclusions. I choose jQuery for  
the experiment, because it is popular, lightweight, and focussed, it  
is elegant in how it traverses and manipulates the Document Object  
Model tree, and it provides a good cross-browser experience. It can  
also be easily extended, and it is backed up by at least two UI widget  
libraries (jquery-ui.js and jquery.tools.js) and a large library of  
jquery plugins contributed by many authors. We standardize on  
javascript version 1.5 and then try other javascript libraries for  
specific purposes, for example, underscore.js for functional  
programming constructs, and jquery.defer.js for handling asynchronous  
scenarios.

2. Re-coding process. We examine the ajax calls made by the current  
opac, and amass them into an interactive dictionary that details  
inputs and outputs. A new wrapper around the evergreen ajax methods is  
designed, necessary because there are slight disharmonies in input and  
output formats and it would be useful to have a more 'normalized'  
version of the service calls; we also experiment with providing a  
session and cacheing layer so that the application code does not need  
to worry about session IDs and duplicate ajax calls. Then by using the  
ajax dictionary, a coder tries to mimic current opac behaviour using  
jQuery and its associates. Currently, we choose a neutral 'wireframe'  
theme for colouring and layout. In our haste to move on, we bypass the  
finicky work of properly handling ajax errors and internationalization.

3. HTML templates. One of our maneuvers is to minimize the use of HTML  
files. Currently, we use only two files, one for catalogue searching  
and browsing, and the other for 'my opac' functions. In the body  
element of each file, we define the top-level div containers and then  
leave the rest to be dynamically constructed by javascript code. In  
both cases, the divs define the tab panes of a horizontal or vertical  
tab plugin, which seems suitable to adopt.

4. Plugins and event control. Another of our maneuvers is to analyse  
the current opac web pages, identify units of logical behaviour, and  
try to define jQuery plugins for them. In this way, we aim for a  
composable interface that may prove to be easy to extend and  
customise. For example, we define natural plugins for searching the  
catalogue, displaying result summaries, displaying result details,  
displaying relevant search trees, and so on. Another design issue is  
to manage the complexity of handling UI events and ajax events while  
running in the single-threaded environment that is javascript. This is  
proving to be an ongoing area of experimentation and there are no firm  
conclusions yet.

For the above activities, we use open source tools that can be easily  
installed on all platforms. We use the stable or beta version of  
Firefox and periodically switch over to Safari, Opera, and Chrome to  
check things out. We install Firebug javascript debugger and  
Firequery, a special extension to Firebug to recognize jQuery  
artifacts. We edit javascript files using Aptana Studio or Komodo  
Edit, because of their good understanding of javascript syntax and  
error checking. Finally, we use a distributed revision control system  
called 'darcs', allowing coders to maintain their private code  
repository and to push or pull patches between themselves. We serve  
HTML and javascript files on local apache web servers. However, we  
direct ajax calls to one of our evergreen servers running an HTTP  
gateway, version 1. In order to get around a security barrier enforced  
by the Firefox browser (and by others), we configure the local apache  
server to do 'reverse-proxying' (details available if you're  
interested). In this way, developers have access to all files on their  
workstations and make ajax calls to a real server, without needing to  
set up new server infrastructure.

In summary, we are experimenting with several modern techniques. Each  
technique is simple enough, but when used collectively, the end result  
is an opac client that is the same outside but dramatically different  
inside, more modular in design, and hopefully easier to customize  
because it is simpler to understand. I gave very brief details of our  
techniques and I can elaborate if there is interest. A natural urge of  
ours is to see how well these techniques transfer over to the more  
complicated staff client.

-- 
Steven Chan
BC Evergreen Sitka project
schan at sitka.bclibraries.ca