you don't want to disable buttons after they are clicked
No, i'm not trying to use jedi mind tricks on you.
You really don't want to go down the road of disabling buttons after they've been clicked. Here's what happens... A developer sees that some user with zero patience is clicking the “Process Page” button a million times while the server is processing the request. This is causing havoc, because your click handler for the button is running a million times, and now you have quite a few records in your database, or database errors about duplicated records, depending on how you have your db set up.
The knee-jerk reaction is, “ok, set the disabled property to true on the button after the first time they click it.”
This is a bad idea.
A disabled button doesn't have it's Name/Value pair sent in the form post. Without the Name/Value pair, the serverside has no idea that the button was clicked. So your Click event doesn't get run.
“Ok, so don't disable it. set the onclick event to just return false immediately.”
Ah, ok, this is a little better... but there's still a couple subtle problems. The user is given no visual cues that the button is no longer functional. This doesn't seem like a problem, unless the original button click didn't actually work. Replace “zero patience user” with “patient user with a horrible net connection”. Let's say the first click didn't work because the net connection died while he was viewing the page. He clicks the button, the button is now “disabled”, but the form post doesn't reach your server at all. So he reconnects to the net, and clicks the button... and nothing happens. Your average user has no clue why your form doesn't work, and leaves promptly, never to return. D'oh.
“couldn't the hit refresh to regain the button's functionality?”
That makes 3 big assumptions about the user:
1) They know what a “refresh” button is
2) They know where the refresh butto is.
3) The know that clicking it will solve their problem.
Sure, YOU understand what's going on... you developed it. How would you feel if you needed to stop your car, turn it off, turn it back on, and continue driving... when you've hit the turn blinker too many times in a row. It's just a horrible answer.
So anyway...
The real answer to Mr Zero Patience Guy is on the serverside. Make your db design able to handle multiple calls to the “Process Page” button gracefully. Now, I don't know enough about bulletproof db design to give you the best-practice for that... It'd depend on your existing db design and processing model, i'd imagine... but trust me, this is where the answer lives.
UPDATE
Alert reader Nicole commented here that the db isn't the best place either. And I agree. I was getting in a hurry to finish the blog entry, and kinda misspoke. I meant to say that the solution is somewhere on the serverside instead of the clientside, whether it be in the db, business layer, or UI layer of the server code. She pointed at a post she's made before about a “submission tracker” concept that I've seen before. And tho I've never seen any actual code samples for the concept, I do think it's a good plan.