Re: How to make injected js execute?

ooops, just last note about external JavaScript injection .... I wrote
this post many months ago.

What kind of browser doesn't support them?

http://webreflection.blogspot.com/20...ic-import.html

andrea.giammarchi (AT) gmail (DOT) com said the following on 8/31/2007 2:21 AM:

On Aug 31, 4:07 am, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:
How do you debug code that doesn't exist anymore? There are more reasons
to leave it than there are to remove it. It is a choice. I choose to
leave mine.
my debugger works fine and DOM is not persintently incremented



Say again? How is me putting script blocks inside a sole div element
obtrusive for every other script?
just think about document.getElementsByTagName("script") ... and just
think about DOM incrementation

My script code is no more obtrusive than any other script block. Do you
remove the script element that you use to contain your script block
also? And, if you know that the script element is there (because you put
it there) then you know you have to deal with it.

The only possible problem that could
*ever* be caused by it is if a div element happened to be duplicated in
which case the script (mine) could be modified to create it's own div
element to use.
there are more problems than one ... but leave your personal DIV there
if You feel lucky.
Use this practice at your own risk if You use third party libraries.

I don't. Most are written by the kind of people that believe that your
script is a solution to the problem at hand.

What is foolproof on a PC is to set the .text property of a script
element. Trying to do that on other OS'es is a recipe for disaster.
disaster ... LOL!!!

Yes, as it will fail in half of the browsers out there.

But it does *not* work in 7 mac browsers (and that is only the ones I
know about).
as I've said, I don't have Mac and I don't care, usually, on browser
used by 0.01% of net surfers.

I am not going to argue with your useless worthless statistics about a
point that I know to be valid. If you want to continue to believe your
crap percentages, then do so.

However, thank You for your link, it seems that my basic proposal,
that I've never called perfect but I called them *proposal*, need just
a simple try catch or to be wrote differenlty for iCab and others
using TextNode, really simple, isn't it?

You mean that garbage, err code, that relies on navigator.userAgent that
sends Safari3 on Windows down the wrong path?

Well done, I'll update my code ... so, at this point, totally amount
of 2 hours against 7 years? :P

And I have code that is 99% fail proof, you have code that is 50% fail
proof.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

andrea.giammarchi (AT) gmail (DOT) com said the following on 8/31/2007 4:51 AM:

Ok Randy, You have a credit inside my code update.

Please remove my name from your code as I don't want to be associated
with it in its present form. It isn't worth using on a controlled
Intranet much less the web.

Last line, that doesn't require above clear function and it should be
cross-browser enough to forget this problem, could You confirm it?
http://www.devpro.it/code/163.html

Confirm that it doesn't even come close to satisfying a "cross-browser"
desire? Sure, I can confirm that.

Sorry for my self-packing obsession, however if someone is interested
about source, just indent (beautyfing) them, it should be quite clear
to read / understand :-)

It isn't worth reading and trying to learn from though as it is fraught
with Bad Practices and faulty coding.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Peter Michaux said the following on 8/31/2007 10:16 AM:

On Aug 31, 1:51 am, andrea.giammar... (AT) gmail (DOT) com wrote:
Ok Randy, You have a credit inside my code update.

I'm curious if he wants credit in your code.

I want nothing to do with it in its present state as it doesn't even
qualify as decent code much less good code.

<snip>

In addition to the brittle dependence on navigator.userAgent, I see at
least two superficial bugs.

It has more problems than that

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

andrea.giammarchi (AT) gmail (DOT) com said the following on 8/31/2007 4:56 PM:

On Aug 31, 4:16 pm, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:
I'm curious if he wants credit in your code.
Since He spent much more time than me to try to solve this problem, I
add his credits in my code.

If He doesn't want its credits, I'll remove instantly ... He should
just tell me ... I don't need his name in my little, personal,
site ... so I can't see where the problem is and credits was add just
for that "big" browser list and their behaviour

I have already responded to that in two other replies, but please remove
my name from that, ummm, "code".

In addition to the brittle dependence on navigator.userAgent, I see at
least two superficial bugs.
I found one, bad replacement (function(e) instead of E) ... now,
please tell me where's the other.

P.S. brittle dependence, rotlf, sounds like Randy "disaster with
text" ... I write code for Web surfers, do You write code for
crackers?

You don't write code for "web surfers", you write code for "web surfers
that use a UA that fits into my little world of browser scripting ability".

as I've said, I don't have Mac and I don't care,
That is an unexpected attitude for a professional.
come on guys, I wrote JSL many times ago ... so please don't teach me
how much could be cross-browser a script.

Why? You could learn a lot based on what you have written so far.

I'm simply realistic, in real life/job/world, 0.01% of bad browser
choice can't be my problem.

I am curious where you got that 0.01%. Did it come off the top of your
head or out of your posterior as it would be about as reliable from one
place as the other.

<snip>

But where did your two hours get you?
two hours to: write code, do few tests with "every day" browsers,
write post on personal blog, read here (thanks You Peter) ... and
finally, create self-packed cross-browser version.

Can You do better? I hope so

I already have, and will continue to make it even better. That can't be
said for your code at the present time because you have already decided
that it is as good as it needs to be (even though it isn't even close).

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

andrea.giammarchi (AT) gmail (DOT) com said the following on 8/31/2007 5:01 PM:

ooops, just last note about external JavaScript injection .... I wrote
this post many months ago.

What kind of browser doesn't support them?

http://webreflection.blogspot.com/20...ic-import.html

If you want to know if something works or not, you could test it
yourself. Since you don't care about any non-PC browser what does it
matter? Besides, it would be trivial to answer you if you would make all
the code for it easily available rather than having to wade through 4 or
5 pages to find it. No thanks.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

On Aug 31, 11:54 pm, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:

I have already responded to that in two other replies, but please remove
my name from that, ummm, "code".
done, however, thank You for that table

You don't write code for "web surfers", you write code for "web surfers
that use a UA that fits into my little world of browser scripting ability".

Hey Randy, I do my work as you do your one.
At the same time, I don't think I code better than You ... and I don't
think You code better than me too.

You can write code for Commodore-64 too if You like this way and You
think this is a good way to create big size "revolutionary" scripts
using double time to do them.

Why? You could learn a lot based on what you have written so far.
And You could learn a lot on what I written too ;-)

I am curious where you got that 0.01%. Did it come off the top of your
head or out of your posterior as it would be about as reliable from one
place as the other.
http://www.w3schools.com/browsers/browsers_stats.asp

http://www.upsdell.com/BrowserNews/stat.htm

I already have, and will continue to make it even better. That can't be
said for your code at the present time because you have already decided
that it is as good as it needs to be (even though it isn't even close).
I've decieded anything about my code ... it is a proposal, just

modified, and last modified version works with probably every row
present in your table (but if a browser is buggy, it can't be my
problem)

My script code is no more obtrusive than any other script block. Do you
remove the script element that you use to contain your script block
also? And, if you know that the script element is there (because you put
it there) then you know you have to deal with it.
of course ... but don't You never think about other developers that

uses third libraries?
I code like You, everything is "mine" and everything is under my
control ... but if I publish something publicly it should care about
every other library (do You know Open Ajax and similar projects?).

So, do You code only for yourself? I think this is not an error, but
this is not a good practice too, expecially if You public your code
over the net.

I don't. Most are written by the kind of people that believe that your
script is a solution to the problem at hand.
because it's a solution for 98% (ok, ok ... 99.9 is too much ...) of

*USED* browsers ... I usually prefere small "quite totally cross
browser" scripts instead of "totally cross browser" big size scripts.

Of course, it's my choice for this crazy Web world, so it's not the
best way to code, just a personal choice.

You mean that garbage, err code, that relies on navigator.userAgent that
sends Safari3 on Windows down the wrong path?
Uh? last script (and probably first one too) works with Safari 2 too,

should I care about Safari 1 and 0.1 beta too?
I remember a WebKit 0.1 alpha, should I test them too?

And I have code that is 99% fail proof, you have code that is 50% fail
proof.
50% of browsers ... but 98% of surfers

If you want to know if something works or not, you could test it
yourself.
That's what I do everytime

Since you don't care about any non-PC browser what does it
matter?
This is your opinion, not my way to code (and I've recently bought

a Nintento Wii too to code for dedicated Opera version ... do You test
your code for new browsers too or only for "not-so-used" one?)

Besides, it would be trivial to answer you if you would make all
the code for it easily available rather than having to wade through 4 or
5 pages to find it. No thanks.
eh eh ... ok Randy, You are the one!

I didn't know this "place" and probably, if You're one "boss" here,
I'll never come back again.

Good luck with your unique and perfect way to code and find solutions
(really, "only" 7 years for this simple problem? ...)

I went here to talk about my proposal and possible problems but You
talk only about your way to "perfectly" code and your friends agree
with your ego.

So, finally, I respect You because your work is good enough for your
purpose/goals but my work (I write JavaScript from about 10 years) is
good enough for my goals, so We'll probably talk about JS one day but
I'm sure, not "tomorrow" if this is your way to talk about them.

As I said, really sorry (to everyone) for my bad and not so clear
English knowledge and best regards to everyone,
Andrea Giammarchi

andrea.giammarchi (AT) gmail (DOT) com said the following on 8/31/2007 7:33 PM:

On Aug 31, 11:54 pm, Randy Webb <HikksNotAtH... (AT) aol (DOT) com> wrote:
I have already responded to that in two other replies, but please remove
my name from that, ummm, "code".
done, however, thank You for that table

Welcome, that is what I put it up for was for other people to see and
test as I have a local copy I use for personal reference.

You don't write code for "web surfers", you write code for "web surfers
that use a UA that fits into my little world of browser scripting ability".

Hey Randy, I do my work as you do your one.
At the same time, I don't think I code better than You ... and I don't
think You code better than me too.

Fair enough. To date, your attitude has come across as one of "My code
is good enough so nothing you tell me is going to change it". When I
encounter attitudes that come across like that, I tend to get the
attitude I have now.

Why? You could learn a lot based on what you have written so far.
And You could learn a lot on what I written too ;-)

I won't say I can't, I won't say I will. Honestly, I had never
considered appending and then automatically removing a script element
all in one step.

I am curious where you got that 0.01%. Did it come off the top of your
head or out of your posterior as it would be about as reliable from one
place as the other.
http://www.w3schools.com/browsers/browsers_stats.asp
http://www.upsdell.com/BrowserNews/stat.htm

Webstats are useless. My cell phone identifies itself with a userAgent
string that mimics - exactly - my IE7 on WinXP with the exception of the
..NET extensions so it will show up in those stats as IE7 but I can
assure you that it is far from being IE7. So, I don't place a whole lot
of faith in something that depends on a setting that has no resemblance
to reality.

I already have, and will continue to make it even better. That can't be
said for your code at the present time because you have already decided
that it is as good as it needs to be (even though it isn't even close).
I've decieded anything about my code ... it is a proposal, just
modified, and last modified version works with probably every row
present in your table (but if a browser is buggy, it can't be my
problem)

Your approach to handling browsers that can't/won't set the .text
property is to attempt to identify them using the userAgent string and
that is a flawed approach from the start. Knowing that, I typically
dismiss any code I see with navigator.userAgent in it as not being worth
a whole lot to me.

My script code is no more obtrusive than any other script block. Do you
remove the script element that you use to contain your script block
also? And, if you know that the script element is there (because you put
it there) then you know you have to deal with it.
of course ... but don't You never think about other developers that
uses third libraries?
I code like You, everything is "mine" and everything is under my
control ... but if I publish something publicly it should care about
every other library (do You know Open Ajax and similar projects?).

If having an extra script block in a page causes a problem to a library
then the problem lies in the library itself, not in the fact that
another script block exists in the page. Perhaps if the authors of those
"libraries" adopted a similar approach and used a designated container
then it wouldn't suffer from having another script block in the page.

So, do You code only for yourself? I think this is not an error, but
this is not a good practice too, expecially if You public your code
over the net.

I disagree with you on that one. See above.

I don't. Most are written by the kind of people that believe that your
script is a solution to the problem at hand.
because it's a solution for 98% (ok, ok ... 99.9 is too much ...) of
*USED* browsers ... I usually prefere small "quite totally cross
browser" scripts instead of "totally cross browser" big size scripts.

The code in one of the URL's I posted looks like this:

var isIE = false;
/*@cc_on @*/
/*@if (@_jscript_version >= 4)
var isIE = true;
@end @*/


function executeJSString(stringToExecute){
var newScript = document.createElement('script');
newScript.type = "text/javascript";
if (isIE)
{
newScript.text = stringToExecute;
}
else
{
var s = document.createTextNode(stringToExecute);
newScript.appendChild(s);
}
document.getElementById("scriptDiv").appendChild(n ewScript);
}

How is that a "big sized script"?

You mean that garbage, err code, that relies on navigator.userAgent that
sends Safari3 on Windows down the wrong path?
Uh? last script (and probably first one too) works with Safari 2 too,
should I care about Safari 1 and 0.1 beta too?
I remember a WebKit 0.1 alpha, should I test them too?

You missed the point.

And I have code that is 99% fail proof, you have code that is 50% fail
proof.
50% of browsers ... but 98% of surfers

That is what I read. Usually from believers of voodoo statistics but it
is what I read.

Since you don't care about any non-PC browser what does it
matter?
This is your opinion, not my way to code (and I've recently bought
a Nintento Wii too to code for dedicated Opera version ... do You test
your code for new browsers too or only for "not-so-used" one?)

99.99% of the time, I don't have to test it on every browser on the
planet. If you use proper feature detection (which isn't always
possible) and you allow for each possible scenario then you come to a
point where you can be pretty sure of the chance of success of code.

Besides, it would be trivial to answer you if you would make all
the code for it easily available rather than having to wade through 4 or
5 pages to find it. No thanks.
eh eh ... ok Randy, You are the one!

I didn't know this "place" and probably, if You're one "boss" here,
I'll never come back again.

If there were a "boss" here, I probably would have gotten fired a
million times in the last 10 years. No, no bosses here. You are always
welcome in c.l.j.

Good luck with your unique and perfect way to code and find solutions
(really, "only" 7 years for this simple problem? ...)

Actually, I have been working with dynamic script insertion for closer
to 10 years but the actual time I have spent researching and testing it
would probably be about a month or so in cumulative time. But, the
problem isn't as "simple" as you make it sound.

I went here to talk about my proposal and possible problems but You
talk only about your way to "perfectly" code and your friends agree
with your ego.

No, I was not talking about "perfect" code. I was pointing out some
"possible problems" and "known problems" with the code you wrote and you
took it the way you wanted to I guess. As for an ego and my friends, I
don't need an ego nor friends to agree with me when I am condemning the
practice of browser detection and an approach to script injection that I
know to be faulty.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

You detect only IE, in your piece of code, and there's any solution
for innerHTML compatible browsers (while my last piece of ... uhm ...
"code", has it)

At this point, this is a quite steril flame and I don't want to go on
with them.

Best regards,
Andrea Giammarchi

Randy Webb wrote:

Richard Cornford said the following on 8/26/2007 12:10 PM:
Peter Michaux wrote:

snip

if ( data ) {
if ( window.execScript )
window.execScript( data );
else if ( jQuery.browser.safari )
// safari doesn't provide a synchronous global eval
window.setTimeout( data, 0 );
else
eval.call( window, data );

We have already seen the setting the - this - value is not
sufficient for this issue, and that is what the - call - method does.
In this case the code appears to be trying to
use the deprecated feature of JavaScript(tm) where each
object has an - eval - method, though even executing -
eval - as a method of an object may be expected to do no
more than influence the value of - this -.

How is using .call trying to depend on executing eval as a
method of an object?

Isn't that precisely what the call and apply methods do?

Other than that, I don't see anything that even comes close
to what you are describing (I am more curious than anything).

Consider that - window.eval( ... ) - is calling - eval - as a method of
an object, but ECMAScript rules say that - window.eval - will result in
a Reference type with a null 'base' property (because window is a
Variable object (at least the global object is a variable object for the
global execution context) ). In practice that should make no real
difference as then the - this - value would default to the global/window
object anyway. However, in this context it must make some sort of
difference else the line of code would be obviously ineffective and
would not be being used (it is the branch that Mozilla/Gecko browsers
will (mostly) be taking so if it were ineffective that fact should have
been exposed by testing).

<snip>

That window.setTimeout(data, 0) call seems like an
easy solution to the scope problem.

The easiest solution is not to design a system where
the problem exists.

While that is always the "easiest" solution, it is not
always the most feasible solution. I have always said that
an "AJAX type" site should have the backend designed to be
handled by AJAX on the client side. The fact remains though
that not all sites are easily reconfigured to be an AJAX
Site without a complete re-write of the entire site.

Which would suggest that changing the delivery technology is not an
action that should be driven by the whims of fashion.

If your boss comes to you and says "I want our HTML4.01
Strict script infested site turned into an AJAX site by
next Friday", you have two choices:

1) Find another job.
2) Kill yourself to please the person signing the check.

There (probably) will be people for whom those are the only choices (as
there (probably) are (very poor) bosses who will not entertain reasoned
or technical arguments in the assessment of decision making).
Personally, that is a very long way form an exclusive list of my
options. And while my boss does consider it his job to come up with
constant stream of 'new' ideas (usually 3 or 4 a week) he does
understand enough about the business to take those ideas to the various
technical experts he employs, discuss their feasibility and accept that
some of them will non-starters.

Very very few people will take Option 1 in the Real World.
It is trivially simple to take Option 1 in a Theoretical
World.

In the end though, aren't you just saying that given a particular
starting point (that is not an inevitable starting point) and totally
constrained in the direction that is to be taken from that point
(without regard for any technical considerations) the outcome might be
somewhat less than what could be considered desirable? Which is true,
but can hardly be expected to influence or constrain a consideration of
what may be regarded 'good' design/implementation criteria.

Richard.