On 5/14/07, Altay Guvench <[log in to unmask]> 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
|
