Phlip said the following on 12/16/2006 5:30 AM:
Randy Webb wrote:
>>I seem to recall stating the project was not directly for public
consumption.. .
>No, you only commented that you didn't want to use fragile code.
"I'm not ... trying to write a public site..."
<quote>
trying to write a public site using extra-fragile code.
</quote>
Which implies, to me, that it is a public site but you don't want
fragile code on it.
Not sure how much clearer I could have been. Maybe I should have put it up
at the top, to reduce the risk of bragging about standards compliance
awareness...
"This is for a private site...."
>Create a script block, set it's text property, and then appendChild it to
the document. Just remember that it suffers the same security restrictions
as cross-domain scripting. If both documents are yours, it isn't a
problem.
Your sample page, while generally studious, does not actually do anything to
the target page at load time. All it does is load the JS and demonstrate an
'alert()'. This does not prove the JS worked in the context of the target
browser.
It doesn't? The sample page (I assume you are actually referring to the
loadJSFile/ page) is a test page to see where different techniques work
(or fail) in different browsers. All of the results on that page are, to
the best of my knowledge, accurate. I did not do any of the Linux and
Mac testing so I depended on someone else for those results.
I'm not done researching all permutations (including a corroboration of your
createElement(' script') technique at
http://www.dotvoid.com/view.php?id=13 ),
Not sure I totally agree with a few of the things on that page but most
of it seems to be precisely what I recommended you do.
but I have a most curious discrepancy between IE and Firefox to report.
That is always appreciated.
Here's the rig so far:
function evaluate(doc, sauce)
{
var s = doc.createEleme nt('script');
s.text = sauce;
var head = doc.getElements ByTagName('head ').item(0);
if (head)
{
head.appendChil d(s);
return;
}
head = doc.head;
if (head)
{
head.appendChil d(s);
return;
}
}
function update_grinder( sauce)
{
var grinder = $('grinder');
if (grinder)
{
var doc = grinder.content Document;
if (!doc) doc = grinder.documen t;
if (doc)
{
evaluate(doc, sauce);
return;
}
}
document.write( "your browser sucks");
}
Now suppose the 'sauce' contained your favorite JS line in the whole world,
'Element.update ("update_me" , "here I B");'. And suppose both the outer and
inner HTML have a <span id='update_me'> . When I run that code....
I assume you are referring to some HTML that looks something like this:
<span id="update_me"> some text or code<span id="update_me"> </span></span>
Where you have multiple instances of the ID nested within one another.
What a browser does with invalid HTML is a guess. You could test it in
100 different browsers and you could possibly get 100 different results
(you wouldn't but it's possible) because ID attributes *must* be unique
in a document. It's the "garbage in garbage out" situation and to be
able to successfully script a document it behooves you to produce valid
HTML.
- IE updates the wrong $('update_me') - the one in the outer HTML
It updates the first one it encounters.
- only Firefox gets the context right and evaluates the inner HTML.
It updates the last one it encounters. Nest 8 of them and see if that
pattern holds true - it will.
Konqeror and Opera did nothing. Naturally, when I take out the outer
'update_me', IE just gives an error.
Without seeing a simple test page that demonstrates it nobody can do
anything but guess as to why.
I am open to the possibility of a bug in the $() inside of prototype.js,
which is where I will investigate next, but does that make Firefox the wrong one?
I would venture a pretty good guess that it isn't a bug in $() as all it
is is a wrapper function for getElementById and whether that is the
cause is easy to test. Replace $('ID') with
document.getEle mentById('ID') and test it again.
So it would seem your page tests alert() more thoroughly than it tests the
issues of javascript insertion...
No, it doesn't. The alert's that get produced (or don't) from the first
three buttons exists in an external file and the only way you get them
is if the browser supports that method. The alert could very well be
anything else I wanted it to be. It could insert HTML snippets in the
document somewhere (and I am actually considering changing it to do just
that).
The last 2 buttons create a dynamic script block and again the alert is
only a mechanism to show success. It could update a div/span in the
document to produce results.
The *only* way you get the alert is if the underlying mechanism to
create it is successful. If it isn't, then you don't get an alert.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ -
http://jibbering.com/faq
Javascript Best Practices -
http://www.JavascriptToolbox.com/bestpractices/ 
