views:

59

answers:

4

Hello Everyone, I am new to javascript/jquery . I have a small question. I have some thing like the following in the java script file.

<button id="button1" onclick=click() />
<button id="button2" onclick=click() />
<button id="button3" onclick=click() />

so the click function looks like the follwoing

click(id){


/do some thing
}

so my question is when ever the button is clicked how can we pass the button id to the function.

<button id="button1" onclick=click("how to pass the button id value to this function") />

how can we pass the button id like "button1" to the click function when ever the button is clicked.. I would really appreciate if some one can answer to my question..

Thanks, Swati

+2  A: 

I advise the use of unobtrusive script as always, but if you have to have it inline use this, for example:

<button id="button1" onclick="click(this.id)" />

The unobtrusive way would look like this:

$("button").click(function() {
  click(this.id);
});
Nick Craver
I'd recommend modifying the function over using this redirection oddness.
Stefan Kendall
@Stefan - I agree you can compact it even more....*maybe*, it depends how it's being used...also use `this.id`, `$(this).attr("id")` is very wasteful :)
Nick Craver
One note, not necessarily related to your solution, but it seems that using the word `click` as a function name fails when referenced in an inline handler. http://jsfiddle.net/ruXfZ/ Changing the name fixes it. http://jsfiddle.net/ruXfZ/1/ Not sure why. Only tested in Safari. Just thought I'd mention it. +1 :o)
patrick dw
@Nick Craver: wasteful beacuse it will take a few extra nanoseconds for the browser to respond to the click? The user probably won't get bored in that timespan. If you are worried about wasting CPU cycles, you shouldn't use a framework in the first place.
Tgr
@Tgr - It's good practice to not use 40 steps where 1 will do...this goes for programming in any language on any platform, if you're in a loop it's not nanoseconds, it can really add up.
Nick Craver
Unless you are doing something seriously weird, an event handler will never be called from inside a loop, and the user interaction speed will be the bottleneck.
Tgr
@Tgr - I was more referring to the fact you *never* have to use `$(this).attr("id")`, in a click handler, a loop, etc...wherever you're using it, it doesn't matter. It's better to get in the habit of writing more efficient code, what exactly is the downside to that? :)
Nick Craver
@Tgr - Certainly you can appreciate that `$(this).attr("id")` requires that you type more than 2.5 x the characters compared to `this.id`. :o)
patrick dw
Personally I find it easier to read. `this.id` could be anything, but it is obvious at first glance that `$(this).attr('id')` is the `id` attribute of a DOM element. (I have to admit though that patrick does have a point :)
Tgr
Time doesn't matter, actually. IE stops responding after *number of operations*, which is the craziest shit I've ever heard of. I've actually hit the IE performance barrier when using large data sets and some complex jQuery interactions.
Stefan Kendall
That said, if you're outside a loop, I'd just use $(this).attr("id") to be consistent. You never know what IE is going to break. $(this).attr("colspan") works in jQuery 1.4.2, because it converts colspan to colSpan under the covers. I feel more comfortable referring to ALL variables as attr("..."), as that requires less developer knowledge to trust the code base. If you're a one-man team, go for it, but if I saw raw attributes in JS I'd get suspicious.
Stefan Kendall
@Stefan - Raw JS attributes that are 100% compatible cross-browser...why *wouldn't* you use the most efficient route? If I saw `this.id` instead of `$(this).attr("id")` I'd immediately have a higher opinion of the coder, not kidding about that at all. There's always 30 ways to do something, why you wouldn't use the more concise, faster, and simpler route is beyond me.
Nick Craver
Because not everyone is a JS guru. If you're working on an enterprise application with a weaker emphasis on the front-end, where developers shift between front-end and back-end, code that's understandable is better than code that isn't. At some point, you can't work at the lowest common denominator, but I'd rather have the standard be "always use attr" than not, for aforementioned reasons. Development time costs money, and the trade-off between a slightly-slower javascript execution versus the time spent debugging why "colspan" won't work can be huge. It's a business effect statement.
Stefan Kendall
@Stefan - Dumbing down code to make it *way* less efficient isn't a good practice, if someone can't read `this.id`, maybe you should hire someone else for the JS work? That's not trying to be a smartass, that's a very serious observation. This isn't an advanced topic, it's *very* basic JavaScript. And I wasn't referring to `colspan`, I was referring to standard attributes that are 100% compatible cross-browser (and that's *most* attributes)...I *specifically* stated this :)
Nick Craver
You don't understand. It's not obvious from code which attributes are basic; there's no reason colSpan, and the other attributes jQuery fixes, should be special. As such, using jQuery as a standard practice eliminates the guesswork. In my LOW, the front-end is just the representation of the data. It's not critical that it be flashy or nice, as the majority of the work is server-related. This has the direct effect of a team of enterprise Java developers creating front-end pages which probably aren't optimal by any measure, but they're functional enough to get the data out.
Stefan Kendall
It would be stupid to hire a "javascript guy" when the majority of the work is server-based, and everyone will likely need to touch the front-end due to the vast horizontal nature of the development. Saving development time saves money, and allowing non-front-end developers to develop front-end code with little issue is important, and it has a direct financial impact on the business. If this means that the page takes 0.3 seconds longer to render, it doesn't matter. Our customer would likely rather wait 0.3s than pay for the dev time required to train a team to become expert JS developers.
Stefan Kendall
@Stefan - That's fine *in the context of your situation*, but making these recommendations in general for all projects I strongly disagree with. *To you* it saves to development time, *to me* the extra keystrokes alone are a waste of development time...and it's more to read every time I view the code in the future as well (that goes for my team members as well). Be careful not to confuse your projects and experiences with *all* projects and teams that are out there.
Nick Craver
+1  A: 

You don't need to.

function handleClick(){
    //use $(this).attr("id");
    //or $(this) to refer to the object being clicked
}

$(document).ready(function(){
   $('#myButton').click(handleClick);
});
Stefan Kendall
A: 

For starters: Don't use onclick(). This is the way to do it properly.

When you get your head around all this and think "boy that's a load of cowpat to write for a litte event!", turn towards jquery.

Doing the same in jquery is simple.

Here Be Wolves
+1  A: 

That not very jQuery-ish. You should rather use event listeners:

$(function() {
    $('#button1,#button2,#button3').click(clicked);
    function clicked() {
        // "this" will refer to the clicked button inside the function
        alert($(this).attr('id'));
    }
});
Tgr