On 5/14/07, Altay Guvench <[EMAIL PROTECTED]> wrote:
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.
I examined part of your code and saw that, but I had thought you'd be
using document.write(), which of course won't work after the page has
completed loading. I have to say that I find JavaScript security a
rather confusing issue (it doesn't help that, for instance, different
browsers cannot agree on a common set of rules - that's with respect
to XMLHttpRequest, however.)
I suppose the major difference between allowing XMLHttpRequest and
allowing access to DOM elements is whether JavaScript from site X can
force the browser to send a cookie to site Y (everything else it can
already send, in particular all content that's reachable from the
DOM.)
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.
Yes, that's what I was advocating. I find it crucial to move this from
the level of JavaScript hack that only experts can apply to a level
that average HTML coders can use and understand.
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.
Additionally, in some cases, even though you could, you may not want
to manipulate the HTML, but rather prefer to post-process it on the
client side. For instance, for the new book list, we have client-side
JavaScript go through the records listed, add in the necessary
widgets, then tell the library to reprocess the widgets. That's
because someone else wrote the software to create the booklist.
- Godmar
