Yanick wrote:
Ressources are not saved between page transition.
Does "resource" have a specific (i.e. formal) meaning here? It's clear
that *some* information can be retained, but not (apparently) variables
and fields.
>Thereof, any declared
window object will be lost when you replace the page content with other
date (leaving the other--popup--window opened).
I don't understand; my demo shows that we *can* get the window object
(or one that is equivalent) and retrieve the *modified* HTML within the
old popup document. (That is, the old document retains any *changes*
made to its structure instead of just reloading "popup.htm" ).
Perhaps we're using the word "object" in slightly different ways. The
general problem I had (as I see it) is that when "second.htm " replaces
"first.htm" in the main window, we cannot transfer a *reference* to the
object.
Perhaps I'm incorrectly applying a Java-centric view of objects to
Javascript, but I'm assuming there's a single underlying window object
that we can have more than one reference to.
There is a few dirty
"hacks" to accomplish what you're trying to do,
Absolutely; my technique belongs to the "informal and messy" category
:)
I didn't test this, but maybe it's a start :
Your technique is interesting; I see what you're trying to do. I
haven't tried it out myself either (sorry :) ), but I see some
potential pitfalls:-
FIRST: The opened window only knows about the opening window by name.
It doesn't know about other windows its parent has opened (before OR
since the current window was created). And parents only "know" about
their children, *not* grandchildren, etc. (i.e. we have a tree-like
structure)
So although it's possible to find every window by name, we (probably)
have to find the tree root, then traverse some (or *all*) of the
branches to find the entry.
One solution might be to modify your code to either (a) Point to a
shared array containing all window names, or if that's not possible
with Javascript, (b) Copy the contents of the parent window's name
array.
Problem with (b) is that you then have to make sure that all the arrays
are kept up to date.
SECOND problem:
Here:-
window._linked[name] = window.open( url, name, options );
window._linked[name]._linked[window._windowN ame] = window;
I've got a horrible feeling that this may run into problems because the
new window won't be fully loaded when the second statement executes. I
might be wrong, but don't we have to wait for the window to load? How
do we do that synchronously?
Oh, apparently we can't.
(Disclaimer: I am *not* a Javascript expert. If I'm wrong, please
correct me, but I haven't come across solutions to the following
problems so far).
Sure, we can callback asynchronously via onload and friends. The major
problem (and one thing I really hate about Javascript) is that there
are times when you *don't want* to do things asynchronously; you'd like
to wait for the page to load.
AFAIK, it's not even possible to loop, doing a periodic check on some
attribute in the (new) page until it has loaded. Why? Because JS
doesn't support sleep(), so we can't put a reasonable gap between
checks. But a busy loop (e.g. while (! childWindow.che ck) { /* empty
loop */} ) has horrific effects on the browser performance (almost
locks it up).
I came up with a rather clever (I thought) solution to sleep() once. It
was simple; psleep() created and sent a *synchronous* XMLHttpRequest
for a "sleep.php" document, with the requested delay specified via
arguments. The document included some PHP code which caused the
*server* to sleep() for the requested number of seconds before
returning an empty (or irrelevant) document. The client, which was
waiting synchronously, was also delayed. Smart idea.
It didn't work.
Well, not under Firefox at any rate. The whole browser locked up for x
seconds, which wasn't the intention. Clearly, my best-guess mental
representation of Firefox's threading was faulty. Pity.
Why the *#$^ doesn't Javascript support sleep()? Seriously, there must
be a good reason for it, because it's a major PITA. Yes, I *know* about
setting timers/timeouts, etc., but they are *not* replacements for
sleep(); they have the same problems as described above.
Anyway, we now return you to your usual programming (no pun intended,
*cough*):-
Well... this is most likely to have a memory leak at some point, it
could be a start...
Leak? I hope not. AFAIK there's no manual malloc() in JS, so a true
leak would indicate a bug in the underlying implementation. Even valid
memory usage isn't likely to be that big for any app with a usable
number of windows...
- MCh
