Can i check out how many times a button is clicked on the html page? Or can i restrict the button to click only one time? If the user again clicked on the button then it wont give any response??
yeah you can. assign it an id, like id="mybutton" do <script type="text/javascript"> document.getElementById("mybutton").onclick = function() { // do normal stuff. this.onclick = function() { return false; } } </script> PHP: after the first click it will stop the running of the onclick event function and return false instead.
you must assign an id to the button, like so (tested this and it works, it only alerts once): <html> <body> <button id="mybutton">click me</button> <script type="text/javascript"> document.getElementById("mybutton").onclick = function() { // do normal stuff. alert("hi, your click has worked"); this.onclick = function() { return false; } } </script> </body> </html> PHP: if this is a form and you are talking about the submit button (don't want it submitted again), then it's a different matter - but similar.
return false in unnecessary, just keep it an empty function, set it to null or even delete it. also you _should_ put semicolons at the end of each javascript command. this.onclick = function() {}; //or this.onclick = null; //or delete this.onclick; PHP:
that's just nitpicking.... i know it can be deleted - this is just an example to illustrate a possible solution. it may be that he does not want to delete the function, but do something else instead, like alter them they've already clicked. as for semi colons at the end of each javascript command - i did not realise this also applied to function definitions that are clearly delimited by curly braces... although come to think of it, if i am creating a json object like... var foo = { bar: 1, bar2: 2 }; Code (markup): ...i tend to always put the semi colon (can't hurt). anyway, if I had to do this in mootools, it would go like $("mybutton").addEvent("click", function(e) { new Event(e).stop(); // kill default action (like submit) this.removeEvents(); // removes all events. if it has mouseovers etc, then you can removeEvent() specifically (just not anonymous functions) // if in a form, call the submit method manually via form.submit() or ajax it. // ... // continue to whatever. }); PHP: vanilla js is not for me
No, its not just nitpicking. Stuff like this matters because it adds up. Adding a return false to an empty function just to remove it is overkill and one might assume that there is a reason you put return false, and not just an empty function. So keeping it as lean as possible has many benefits. Yeah, I used to be in the same boat but then you realize that function or no function, you are just assigning a value (in this case, a function) to a variable. I, however am of the other opinion. You learn much more when writing plain JS and are much more flexible. Leave JS libraries to basic consumers / designers ; by all means. Or JS devs who just want the quickest path to completion.
i am sorry but we will agree to disagree. Using a framework does not cheapen / devalue one's javascript skills to the level of a 'mere designer' or a consumer. Such a statement on any of the frameworks' mailing lists will bring nothing but ridicule... And by god, there are some talented people out there! On the contrary, I believe framework usage does the exact opposite of that: it lays a solid foundation you can build on in a cross-browser compliant way w/o having to worry too much about quirksmode.org being your homepage. True, there will be a degree of people that use one for a lack of understanding; or simply because a framework happens to power-up whatever lame lightbox/thickbox plugin they've found the net. I don't care either way--but I should not have to care if a particular browser does not send a "load" event when most others do and returns a "ready" instead. My framework will do that for me. Same way as I am not too worried about IE6 not having background images cache, my framework enables that for me too. As well as a tonload of other fixes, selectors, shortcuts etc being made available. All of this leaves me in a better position to quickly, accurately and in a patterned way deliver what is expected of me - cutting edge content rich dynamic browser applications. This is not about the "quickest path to completion", it is about the _right_ path. And let me tell you something from experience - nobody in any commercial environment will pat your back because you have spent a week resolving a problem that could have been solved by using a framework within minutes. Jesus died on the cross so we don't have to - join the darkside, there is no going back
I hope you're not quoting me because I surely didn't say that. If you want to keep browser quirks workarounds to a library then do so but don't learn javascript with a library, learn it as plain javascript. No advanced javascripter would disagree with that statement.
fair enough then--i agree you can't run before you can walk. rudimentary javascript knowledge at the very least, coupled with at least one other programming language (perl, php, delphi, java, whatever -- won't mention actionscript because its also a derogatory of ecma script) means you can easily tackle javascript. to be honest, until i came across mootools, i looked upon javascript as a necessary evil: an unpleasant experience of fiddling and tinkering with uncertain results across multiple rendering engines... in other words, challenging. mootools gave me a different perspective on things and it actually showed javascript in a different light... it was fun to code and it had also become a powerful OOP language overnight... it's a process of discovery... but one i am taking quite seriously (to the point that now i earn nearly twice as much as i used to do as a PHP / lamp developer before -- with all my years of experience). so... rock on js!