Hi Godmar-
Tim asked me to join the list and discussion on the LibraryThing widgets.
You're right that, with Ajax, we're bound by the same-origin restriction.
But we can dynamically change the page content after loading, by eschewing
traditional Ajax. New content is delivered through dynamically-inserted
<script> tags. For example, you can set an onclick that adds a tag like
this to the <head>:
<script src="http://www.libarything.com/get_content.php?tag=foo"
type="text/javascript"></script>
Server-side, get_content.php generates the response on the fly, e.g. echo "
document.getElementById('tagbrowser').innerHTML = 'books tagged foo'". As
long as the response header in get_content is set to javascript, the browser
should interpret it correctly.
As for the hardwired DOM finagling you saw in Danbury's OPAC, in most cases,
the table[3] stuff isn't necessary. Typically, a library will simply edit
their OPAC's html template to include empty widget divs ( e.g. <div
id="ltfl_tagbrowse" class='ltfl'></div> ) wherever they'd like the widgets.
Then a single script tag finds those divs and inserts the contents onload.
However, there were some permissions issues with the Danbury OPAC that
didn't allow for this. (They could only edit the OPAC footer.) The
workaround was to dynamically insert the LTFL <div>s using custom javascript
in the footer. That said, like I mentioned, this isn't necessary in most
cases. We've tested it in a few systems, and generally speaking, our
widgets are DOM-agnostic.
Altay
---------- Forwarded message ----------
From: Tim Spalding <[log in to unmask]>
Date: May 14, 2007 1:50 PM
Subject: Fwd: [CODE4LIB] A new generation of OPAC enhancements
To: Altay Guvench <[log in to unmask]>
---------- Forwarded message ----------
From: Godmar Back <[log in to unmask]>
Date: May 14, 2007 1:44 PM
Subject: Re: [CODE4LIB] A new generation of OPAC enhancements
To: [log in to unmask]
Interesting. A few questions/comments.
From what I can see, you will not be able to dynamically change the
page's content after it has finished loading, due to the same-origin
restriction. Is this correct? In other words, you'd have to pre-plan
for any user interactivity and send the necessary data along.
We're pursuing a similar approach with the most recent version of
MAJAX. Instead of using <div>, we're using COinS-style <span> tags
currently. (*) We tried to keep the JavaScript to a minimum - the user
shouldn't include anything more than the <script> to pull the
processing JavaScript. Then only plain HTML would be used. (By
contrast, your approach relies on hardwiring knowledge of the page
layout into your Javascript, such as "table[3]" to find out where to
insert your information - and at librarything.com at that!)
My comment, I suppose, is that it may be nice to agree on a set and
syntax of features that people could use to include into their web
offerings - not only the catalog, but other library and even
non-library offerings as well. For instance, a new book list or a list
of resources prepared by a professor for a particular class are
example applications we have prepared for Majax, and they could
certainly be implemented for/with LTFL as well.
- Godmar
(*) See http://libx.org/majax/majaxtalk.html - BTW, Annette will talk
about this in San Jose Wednesday afternoon at the IUG meeting.
On 5/14/07, Tim Spalding <[log in to unmask]> wrote:
>
> I expect many of you will object that both are kludges. We need
> genuinely open and extensible systems.
>
> Of course, I agree with you. All the LTFL widgets are also available
> as XML feeds. And I can't wait to plug them into Evergreen, or
> whatever. But, for now, and for most people, the exsiting OPACs exist.
> There's a lot we can do with them, even so.
>
> I hope that LTFL can inspire a new generation of light-weight OPAC
> enhancements. If anyone wants to talk architecture, I'm more than
> happy.
>
> Tim
>
|
