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 <!cript> tags. For example, you can set an onclick that adds a tag like this to the <head>: <!cript 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 <!cript> 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 >