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

[Joe Atzberger]

Sounds like an interesting project, not without some considerable hurdles.
I am personally a big fan of jQuery, and would love to see it used over some
of the current techniques.  One feat will be to undo the locally defined $
function that conflicts with default jQuery namespace.
My main question: how will this refactoring project relate back to the
mainline?  Is anybody going to try and keep the versions in sync as you go?


When you talk about keeping the functionality "the same", that is easier to
imagine if the target were a static version.  In this case it is much more
difficult to keep it "the same" as the moving target that is the trunk.
That being said, I think everybody would be happy with more modular and
extensible web infrastructure.  I look forward to seeing some of the code...

--Joe

On Tue, Nov 3, 2009 at 5:23 PM, steven chan <schan at vcn.bc.ca> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20091103/4b7abb5e/attachment.htm