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