Trouble adding an OnClick Dynamically.

[Donius]

Hey everyone, i am doing some stuff where i'd like to pop up a little
confirmation before a user clicks on a 'delete' link. Just trying to
keep the markup clean, i added an attribute pre_act="confirm" to all
of the links that i wanted to do this to and am trying to add an
onclick event that will cancel the click action if they fail. I've got
a test page at http://randomwebspace.net/testing/testpage.html. It has
no unintentional XHTML validation errors, and i am sure that i'm
finding the right elements ((i'm also turning their backgrounds red,
just to be sure))...but the event doesn't get attached. Does anyone
see what my issue is?

Basically the markup that i want to affect looks like:
<a class="iconlink" href="http://www.google.com"
pre_act="confirm">delete</a>

And the code that i'm trying ((for this iteration)) to add an onclick
event is:
function fnConfirm(){ return false; return(confirm('Are you sure?')); }
hecConfirmable.onClick = fnConfirm; /*
HtmlElementCollection...called from a loop */

I'm running the loops that call that code once the body has loaded so i
don't think it's an issue of the DOM not being available yet.

Any ideas? Thanks!

-Brendan

 

[ajax]

May be you can try this...

<a href="some link" onclick="return func();">SomeText</a>

and in the function, func() show the prompt and return true or false as
the functions return value.

-Rafiq
http://www.ajaxtoday.com

 

[Donius]

May be you can try this...

<a href="some link" onclick="return func();">SomeText</a>
[snip]

Yes, i certainly could do that and i don't have any particular reason
not to other than i'd like to avoid it if i can. I'd like to add the
onclick dynamically so as to keep javascript out of my markup - does
anyone know how i would work that?

 

[Randy Webb]

Donius said the following on 5/2/2006 2:57 PM:

Hey everyone, i am doing some stuff where i'd like to pop up a little
confirmation before a user clicks on a 'delete' link. Just trying to
keep the markup clean, i added an attribute pre_act="confirm" to all
of the links that i wanted to do this to and am trying to add an
onclick event that will cancel the click action if they fail. I've got
a test page at http://randomwebspace.net/testing/testpage.html.

And you want someone to wade through 625+ lines of JS code to try to
figure out the problem???

Your standard.js has a lot of problems in it though.

 

[RobG]

Donius said on 03/05/2006 6:46 AM AEST:

May be you can try this...

<a href="some link" onclick="return func();">SomeText</a>
[snip]

Yes, i certainly could do that and i don't have any particular reason
not to other than i'd like to avoid it if i can. I'd like to add the
onclick dynamically so as to keep javascript out of my markup - does
anyone know how i would work that?

It's always good to start with valid markup:
<URL:http://validator.w3.org/check?uri=http://randomwebspace.net/testing/testpage.html>

There is no particular benefit to keeping JavaScript out of your markup
when the alternative is adding invalid (X)HTML attributes. I can't see
that it's better to rely on the client executing a series of functions
that perform conditional compilation and browser sniffing, plus search
through every element in the document looking for some to modify, when
the onclick handler could have been added at the server.

How much difference is there between:

<a ... pre_act="confirm" ...>

and

<a ... onclick="return fnConfirm(this);" ...>

from a 'clean code' perspective? Either the additional attribute is
added at the server or at the client. In either case, the HTML author
has to decide whether to add a particular attribute & value or not.
Your server code could use the pre_act attribute and replace it with the
onclick handler.

Also consider if you use the load event to attach the handlers and a
user clicks on one of your buttons before the page is fully loaded, the
onclick handler won't have been added. If page loading is slow, users
will often press Esc several times to cancel loading then try to use the
page as-is - that will stop onload from occurring.

Anyhow, your issues may be cured by fixing fnConfirmations():

hecConfirmable.onClick = fnConfirm;
---------------------^^^

JavaScript is case sensitive, as is XHTML. The property you seek is
onclick.

--
Rob
Group FAQ: <URL:http://www.jibbering.com/FAQ>
"It is much easier for a web developer to create a site
that receives no complaints than to create a site that
doesn't warrant any." --Richard Cornford

 

[Michael Winter]

On 02/05/2006 19:57, Donius wrote:

[snip]

hecConfirmable.onClick = fnConfirm;

Property names are case-sensitive. The intrinsic event properties are
all lower case (onclick, in this case).

[snip]

Mike

 

[Donius]

Responding to everything all at once:

And you want someone to wade through 625+ lines of JS code to try to
figure out the problem???

No man! If it was in my standard.js i would have found it - that code
goes into a good number of sites.

Your standard.js has a lot of problems in it though.

Such as? I know, i browser sniff. For Mac IE 5, which has crashed on
half the JS i've ever used. I'm fine with that. Are there other
problems that you see? I wouldn't mind critique... I can't see much
wrong with it, but if you have anything to mention in that 625+ line
page, i'd be glad to hear it. I'm not even doing anything crazy
like modifying prototypes, which is one of my favorite things *ever*!

It's always good to start with valid markup

I know, i checked the markup...i came back with invalid element
attribute errors (intentional) and some errors due to my using
javascript without enclosing it CDATA sections or however else i'm
supposed to hide javascript from the validator. Is there another way
to include javascripts in-page that works with this? I suppose i could
put them all in external files...

How much difference is there between:

<a ... pre_act="confirm" ...>

and

<a ... onclick="return fnConfirm(this);" ...>

Not much at all! Like i said, i'm doing it this way more or less
because i'd like to. I'm transforming from XML for a good deal of it
and there's no reason i can't use an onclick, but the data is being
used for other things, where 'pre_act="confirm"' also has some similar
meaning, so it seemed most ubiquitous to use that.

Also consider if you use the load event to attach the handlers and a
user clicks on one of your buttons before the page is fully loaded, the
onclick handler won't have been added. If page loading is slow, users
will often press Esc several times to cancel loading then try to use the
page as-is - that will stop onload from occurring.

A very good point, I will take that into consideration.

Anyhow, your issues may be cured by fixing fnConfirmations():

hecConfirmable.onClick = fnConfirm;
---------------------^^^

JavaScript is case sensitive, as is XHTML. The property you seek is
onclick.

My editor autofilled it to onClick! Damned dirty thing! Thank you to
both RobG and Mr Winter for pointing that out. I appreciate it.

Thanks guys,
-Brendan

 

[Randy Webb]

Donius said the following on 5/3/2006 8:30 AM:

Responding to everything all at once:



No man! If it was in my standard.js i would have found it - that code
goes into a good number of sites.

It wasn't the case here, but sometimes code in one .js file can cause
problems in another .js file or in the page itself. var conflicts and
the such.

Such as? I know, i browser sniff. For Mac IE 5, which has crashed on
half the JS i've ever used. I'm fine with that.

That was one of them that I recall.

Are there other problems that you see?

The major one I remember was the document.getElementById emulation for
document.all browsers. I remember that one most because I am, to the
best of my knowledge, the first person to post that code here in c.l.j:

if(document.all && !document.getElementById) {
document.getElementById = function(id) { return document.all[id]; }
}

It works, sometimes, properly in IE4 but it doesn't always do what it is
supposed to do.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Thu, 4 May 2006 22:41:00 remote, seen in

The major one I remember was the document.getElementById emulation for
document.all browsers. I remember that one most because I am, to the
best of my knowledge, the first person to post that code here in c.l.j:

if(document.all && !document.getElementById) {
document.getElementById = function(id) { return document.all[id]; }
}

It works, sometimes, properly in IE4 but it doesn't always do what it is
supposed to do.

Now that's an unreasonable statement, because you have no way of telling
what the person who puts (or reads) it on a Web page supposes that it
will do.

If it is supposed that it can be used in any browser to ensure that
document.getElementById will be available with full customary
semantics, then AIUI it will not always do that.

But if it is supposed that, where a page contains <div ID=XYZ>..</div>
and there is no other XYZ in sight, the constructed getElementById can
be used to get a reference enabling the contents of the div to be
changed, then AIUI it will work.

It is, AFAIK, a partial emulation of the full version, and reliable
within the limits which its author should have expected.

 

[Randy Webb]

Dr John Stockton said the following on 5/6/2006 11:32 AM:

JRS: In article <[email protected]>, dated
Thu, 4 May 2006 22:41:00 remote, seen in

The major one I remember was the document.getElementById emulation for
document.all browsers. I remember that one most because I am, to the
best of my knowledge, the first person to post that code here in c.l.j:

if(document.all && !document.getElementById) {
document.getElementById = function(id) { return document.all[id]; }
}

It works, sometimes, properly in IE4 but it doesn't always do what it is
supposed to do.

Now that's an unreasonable statement,

No, it's not John.

because you have no way of telling what the person who puts (or reads)
it on a Web page supposes that it will do.

While that is pedantically true, I know what the original intended
purpose of it was, as presented to me.

The emulation of getElementById in IE4.

<URL: http://www.metalusions.com/backstage/articles/8/ >

Read it yourself. And, anybody who understands the above code gets the
first impression that it is - gasp - attempting to emulate gEBI for IE4.

If it is supposed that it can be used in any browser to ensure that
document.getElementById will be available with full customary
semantics, then AIUI it will not always do that.

And hence my statement that it does not do what it is supposed to do.
Maybe rewording the statement can satisfy the pedantics:

It doesn't do what it was originally written to do.

But if it is supposed that, where a page contains <div ID=XYZ>..</div>
and there is no other XYZ in sight, the constructed getElementById can
be used to get a reference enabling the contents of the div to be
changed, then AIUI it will work.

And only if the browser supports document.all, doesn't support gEBI,
supports dynamically changing an element, and so on...

It is, AFAIK, a partial emulation of the full version, and reliable
within the limits which its author should have expected.

No, it doesn't. Read the website.

<quote>
The following bit of script checks to see if document.all is present,
but document.getElementById is not. If this is the case it then assigns
a new function to document.getElementById that wraps around document.all

if(document.all && !document.getElementById) {
document.getElementById = function(id) {
return document.all[id];
}
}

With this script present at the top of the head section, either in an
external file or an inline script, all that is needed to reference an
element on IE, Mozilla/NS6.x and a number of other browsers is
document.getElementById('theID')
</quote>

And that run on sentence at the end is false.