Peter Michaux wrote:
update: function(element, html) {
$(element).innerHTML = html.stripScripts();
setTimeout(function() {html.evalScripts()}, 10);
},
Why strip the scripts before inserting? Is this only for NS6 browser
support?
As another poster said scripts inserted via a innerHTML are not
automatically executed so they will have to be manually executed. The
reason for stripping them before inserting the content seems to have two
reasons (in my opinion):
* Ensures your DOM does not get messy. There does not seem to be any
purpose in inserting the script node into the DOM so might as well
remove it first to keep your DOM clean. That way if you want to traverse
the DOM you don't have to avoid script nodes.
* It seems like relying on the browser to not execute the script is
fragile. Maybe some browser will auto-execute the code at some point in
the future. Since we are executing it manually might as well take the
time to remove the possibility of it ever being executed more than once.
Why wait 10 ms before evaluating the scripts?
This has to do with many browser's threading model. From what I have
read (and experienced) many browsers do not have a very good threading
models in JavaScript. Basically once some JavaScript code is running all
other threads of execution are on hold until the running thread is
finished with it's task. This includes whatever thread of execution that
updates the DOM model when new content is inserted via innerHTML. For
example if you do:
foo.innerHTML = '<span id="bar">Baz</span>';
var bar = document.getElementById('bar');
This code will sometimes fail because although you added the content via
innerHTML the DOM may not have been updated and therefore the "bar"
element does not exist in the DOM yet. To work around this you can do:
foo.innerHTML = '<span id="bar">Baz</span>';
setTimeout(function() {var bar = document.getElementById('bar');}, 10);
This will work because in 10 milliseconds whatever event handler is
running will have finished, the DOM will update, then the callback will
execute and have no problem accessing the DOM element.
The actual delay time is not really important because the innerHTML
action happens before the setTimeout method causing the DOM update to be
appended to the list of threads waiting for their turn before the
callback is appended to the list of threads waiting for their turn.
Therefore the DOM update should always occur before the timeout is executed.
All of this is similar to the "DoEvents" method in VB if you have ever
used that to cause an interface to update while some long-running
process is executing. It all stems from a light-weight threading model
and is really just a workaround.
Eric
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
