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
[email protected]
