Actually, thinking about this more, I just came up with a way too clever
method to get my availability checking component (which is actually
Umlaut) to deal with client-side-required APIs. Involving a (re-useable)
hidden div that makes the js API calls, gets the responses back, and
then sends those responses _back_ to my server code using an AJAX call,
which the server can then incorporate into it's server-generated HTML. I
already have a nice architecture for AJAX updating of 'background'
services--which was originally meant for background services generated
on the server side, but with the client doing it and then sending the
response back to the server via AJAX, it _could_ work. And still be nice
and clean and abstract. And I could use it both for Google and for other
client-request-required APIs like Scopus's "cited by" service.
It would be interesting to implement, actually, kind of fun. I still
worry that this added complexity is just another place for bugs,
(cross-domain AJAX calls using the <!cript> tag, like these AJAX APIs
use, are kind of a hack to begin with). But since chances of getting
Google to change seem slim to me, might be worth investigating. Hmm.
Jonathan
Godmar Back wrote:
> On Mon, Mar 17, 2008 at 10:41 AM, Jonathan Rochkind <[log in to unmask]> wrote:
>
>> Well, the SFX architecture has a feature called "display logic" that
>> let's you on the server side determine how the menu will display based
>> on what services are available. This is more obviously relevant to
>> "digitized text availability" from Google Books than just cover images.
>> You might want to suppress ILL links if there is digitized text (in
>> fact, you probably wouldn't in that particular case, but that gives you
>> the idea of what things you might want to do. At least my library
>> wouldn't, maybe others with especially small ILL budgets might). Or
>> just give a pre-ILL warning message ("are you sure the Google text isn't
>> sufficient?), that might be more realistic.
>>
>> Anyway, you obviously couldn't do this using the existing SFX display
>> logic feature if the Google Books info is only client side.
>> Now, "impossible?" In the world of software development, few things are
>> actually impossible. You could try to duplicate that feature using only
>> client-side Javascript hiding and showing various DIVs. The SFX HTML
>> currently isn't that clean, it woudl be hard. But you have the
>> capability to customize the SFX HTML however you want to. (And your
>> customizations will likely break with a future SFX release). So
>> nothings impossible, but I wouldn't want to go down that road.
>>
>>
>
> Your particular requirement (hide the ILL link if Google has text) is
> easily implemented using the gbs classes: simply wrap the ILL link in
> a <span class="gbs-if-noview">...</span> and you're done. SFX will
> likely preserve such <span> tags across releases since it doesn't know
> what style you're applying.
>
> If I were you, I'd probably look for a server-side solution first,
> too, but let's discuss the architectural differences a bit more.
>
> You mentioned modularity and maintainability - I'd say that a
> client-side solution can be kept modular and maintainable as well - in
> particular if you minimize the actual JavaScript code you embed in
> your output page.
>
> In addition, client-side has significant advantages in both latency
> and scalability, in particular when mashing in data from a provider
> with a distributed architecture that has a degree of redundancy, and
> therefore availability, that is as high Google's.
>
> - Godmar
>
>
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
