"Randy Webb" <Hi************ @aol.comwrote in message
news:n7******** *************** *******@comcast .com...
Jim Davis said the following on 7/20/2006 11:42 AM:
>"Jim Davis" <ne********@vbo ston.comwrote in message
news:dr******* *************** ********@gigane ws.com...
>>"Randy Webb" <Hi************ @aol.comwrote in message
news:3P****** *************** *********@comca st.com...
PJ said the following on 7/19/2006 10:43 AM:
Greetings.. .
>snip<
>Actually I've fibbed a little.
Actually, it was a lot, not a little.
Well... I _thought_ it was a little. Turned out it was a lot. ;^)
>So to just let injected script run (in IE) you need to just set the
"defer" attribute.
Or extract the text of the script element, re-create it and you are done
in any browser that supports createElement and appendChild
Of course your solution has one caveat...
IE will run the code as is using "defer", Firefox will not. Using just the
script recreation code you posted with "defer" will actually run the code
TWICE in IE.
You can simply run the script without "defer" of course - and this is by far
the simplest method, but you are doing work not required by IE. If you've
got a lot of code then you may want to make the decision to do a bit more
complex and only run the script recreation in Firefox and not in IE.
Also note that, as is, your code will actually create duplicate script
blocks (dump the contents of the DIV to see this). I would take the effort
to remove the original code blocks. Adding a line like the following within
your loop should do it I think:
d[x].parentNode.rem oveChild(d[x]);
In initial tests this seems to work fine. I would have liked to simply
replace the original blocks with the new blocks but I couldn't discover a
method that would both replace the block AND run it.
>For example if you had a function called "Init()" in multiple pieces of
content IE would always run the first instance loaded into the DIV UNLESS
you "null" the container before loading the subsequent block.
That is about as far from true as you can get.
Well I can get much, MUCH farther from "true" but that's beside the point.
;^)
As I noted when falling on my sword with Richard after testing it I
discovered that I was indeed wrong. I'm going to do a little more digging
since I wrote the original code under IE 5 and I can't test that readily.
I'm generally pretty anal about commenting all "odd" things and this has a
large, elborate comment concerning the need to "null" the container.
Even if I'm wrong I'm curious how I came to the conclusion. It may be for
some other reason and I'm misrembering. In any case I'm definately wrong
concerning IE 6.x.
Oh... one more aspect of this when injecting script into DIVs to simulate
new "pages".
Injecting the script element is all well and good, but as we've seen doing
so is the same as running that script globally: replacing the content of the
DIV does not (as you and Richard have pointed out) eliminate script
declaration previously made regardless of the content of the DIV. Functions
set, global variables declared, etc will persist unless explicitly
overridden.
Automatically "knowing" or discovering which declarations were made by the
script blocks in question could be nightmarishly difficult.
To address this, as I mentioned before, you can create a container for the
page-specific material - a sort of pseudo-scope. Create, for example, a
global object called "Page" and place all of your page specific functions,
variables, etc within it.
For example:
Page = new Object();
Page.myVar = value;
Page.Init = function() {};
.... and so forth.
If each "page" loaded reinitializes that "scope" object (or, better, a
global page loader method manages it) then you'll be reducing the amount of
"baggage" left around as pages are loaded and the application is used.
Jim Davis