So if you enjoy writing the code twice, in two different languages, and maintaining that, that's fine.

If you don't have unlimited programmer resources, then write only the serverside check. Don't skimp and write only the clientside check, unless you want your name on a posting as a CERT warning or BugTraq posting as the "loser that wrote this code" {grin}.

-- Randal L. Schwartz, Perl hacker

Um, in that code there is no need for a server-side check.

A non-JavaScript page may be needed for the merlyns of this world to access the page, but as it stands if the page comes back to the server then the user has already confirmed and you should do the action (assuming that the user is validated and all that).

In short the pop-up is a slight change for the user UI. If you don't have JavaScript then you don't get a chance to change your mind after hitting the big button.

Regards,
Ben

PS I know how you feel about JavaScript. Doesn't change the fact that a lot of people are told to use it in a work situation. People are paid to program in VB as well.

EDIT
Apparently I misinterpeted some comments yesterday. Sorry about that. I *didn't* know how you feel.

PS I know how you feel about JavaScript. Doesn't change the fact that a lot of people are told to use it in a work situation. People are paid to program in VB as well.

If you "know how {I} feel", your statement makes no sense. {grin} I don't mind that people write JS code, and even get paid for it.

The conflict is when they use it to provide essential navigation services, or to provide client-side-only data validation. The former makes the site useless for many people. The latter is a security hole.

I'm a very practical guy. Use whatever language works. Clientside JS does not work for either of the above cases, regardless of whether you are paid to do it or not.

-- Randal L. Schwartz, Perl hacker

Perhaps I should have gone into a little more depth before showing that code. I agree with you that JS shouldn't be used as a substitute for serverside checking of valid data, but I disagree that JS has no use as a confirmation tool.

I use this code actually primarily when writing in-house, intralan web sites, where javascript enabled browsers are the norm. In this environment, a JS popup box is very practical, I find it ugly to have to present the user with another confirmation page, with buttons for yes/no, or what have you.

Perhaps you know of a better way to present the kind of functionality I'm talking about, and I would gladly like to hear about it. Untill then, I wil stand by my practice of using JS as a confirmation tool.

I often use javascript in perl functions to validate user input, rather than having my perl script check the inputs.

Something like this ..

print<<CHECK;

<script language="JavaScript">
   if(window.confirm('Really delete $entry?')) {
    location.href=("$0&aktion=Delete&confirm=1");
   }
   else {
    history.back();
   }
</script>    

CHECK
[download]