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

[Dan Scott]

Hi Steven:

On Tue, 2009-11-03 at 14:23 -0800, steven chan 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?

In the short term, I'd love to see the legacy hand-crafted JavaScript in
the OPAC refactored to adopt a standard cross-browser JavaScript
library.

jQuery is certainly the popular choice amongst projects for a
cross-browser JavaScript library today, but unless you're willing to
either load both Dojo + jQuery to get the job done, or to throw out the
custom Evergreen Dojo extensions that already exist such as
openils.fieldmapper for invoking services and instantiating objects via
the HTTP translator, I'm not sure that jQuery is the best choice for us.
Dojo offers all of the features that you listed for jQuery, with the
exception of popularity. Poor Dojo. That said, beyond relatively small
changes like adaptations of Alex @ UPEI's Google Preview code to use
Dojo, to introduce internationalization of dynamic strings in the
reporter via Dojo, and to implement the MFHD add/edit/delete buttons in
the staff client via Dojo, I'm not the one doing the experiments you've
laid out - so feel free to ignore my thoughts; working code wins, right?

In the longer term, I would advocate moving away from an AJAX-centric
OPAC and moving towards an OPAC that builds the bulk of the page in
plain old HTML on the server side, then use JavaScript for extra
flourishes. The reasons here are two-fold: first, search engines can do
a far better job crawling plain old HTML (that's making the assumption
that visibility of your library's records in general search engines is a
goal); second, cutting down on the dependency on AJAX to provide the
core display data and making all of the corresponding calls on the
server side before returning the HTML should result in much lower
latency for the client, which could only make users happier.

Those are my knee-jerk reactions, anyway, so take them for what they're
worth. It sounds like you're doing some really interesting work, and I
am quite interested in what you're going to come up with!