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

[steven chan]

On 3-Nov-09, at 7:32 PM, Dan Scott wrote:

> 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.

Hello Dan, I wasn't advocating replacing dojo with jquery. In point  
one of my brief report, I explained why I chose jquery as a good  
design tool for the exploration that I was doing, that's all. An  
implication was though to urge that some sort of javascript library be  
used to replace the large set of utility functions that is used in the  
current opac. I see that dojo has now been chosen, but I also see that  
it hasn't been retrofitted to the opac yet, perhaps in the near  
future. Mike in his reply has pointed out the new javascript coding in  
version 1.6, which I am just starting to inspect.

> 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.


As I said in my reply toJason, I think one of the strengths of the  
evergreen system is its rich ajax API. It does need careful coding to  
reduce latency. We have tried putting a simple cacheing layer to  
reduce the ajax calls; it seems to help for certain interfactions. We  
have also resequenced the ajax calls in some of the web pages to be  
more parallel, which helps as well. This last step is made easier if  
the code is re-organized to make the inherent parallelisms more  
visible, otherwise one can't see the possibilites. I think we should  
keep being using ajax but remove latencies through new coding  
patterns. In any case, the search part of the opac is the 'smaller'  
part of the interface; the bigger part is the my opac interface and  
there it makes sense to use ajax.

-- 
steven chan
BC Evergreen Sitka project
schan at sitka.bclibraries.ca