"Jacob JKW" <ja******@yahoo .comwrote in message
news:11******** *************@7 5g2000cwc.googl egroups.com...
Having read the CLJ FAQ and having done extensive Googling, I do
understand that in in general cross-domain iframe scripting is not
permitted. One issue I have not seen directly addressed, however, is
scripting across different but still "friendly" domains.
Essentially I'd like to send a signal from the child to the parent in
any form at all. I would think that there might exist a way to set some
variable or object property that could both be read by the parent and
written to by the child (or vice versa).
Am I just totally wrong?
I've often thought there _should_ be a system for this - some extension the
browser object model that provided for a "public" scope which which you
could store information visible to anybody. But there isn't.
I once played extensively with this. The most successful failure I had
dealt with setting asynchronous messages in the status bar in one frame and
reading them in another. It worked, mostly, but not in all browsers (if I
remember correctly at the time it worked in IE 4, 5 and 6 on Windows and
Mozilla... but oddly enough not on IE 5.5 - or something like that).
Even if it did work across all browsers it would almost definately have been
seen as a security bug and fixed to eliminate the (already very tenuous)
connection.
One thing you can do is consume script from another site. Although the
script itself is then considered "local" (it's run with the same privledges
as if it were loaded from the containing page's server) it can, of course,
contain "special" information from the other server.
We use this, as an example, in a site were the "main site" frames some
information from an affiliated site. The main site has left-hand navigation
and a bread-crumb trail that the affiliated site needs to mimic. So we've
encapsulated all of the code for those into a JS file: both sites call the
same file and can display any state of the navigation. The main site passed
query-string parameters to the affiliate site when it's called to let it
know the state of the navigation so that the two match.
Although in reality there are two sets of navigation (one per site) it
_looks_ like one set, one site, and we only have to maintain one file with
the information.
If you set cookie or query-string variables on the call to the script itself
you can pass information to the other server (although this would have to be
dealt with by a server-side component, not client-side javascript which
wouldn't have access). But simple server-side script could inteperate the
information and dynamically generate the client-side script (this is, in
fact, what's done by many banner-ad aggregators).
An image call (for example) could also be used to send such information to
another server.
The server would stow the information someplace which could be retrieved by
the client-side script in the other frame. In this way (badly explained I
know) the two sets of client-side scripts, separated on the client-side,
could use a server-side conduit to "talk". It's ugly and slow and messy but
it would work.
But as far as real client-side communication.. . I doubt you'll see one.
Even if you do find a hack don't expect it to stay available. ;^)
Jim Davis
