-- Randal L. Schwartz, Perl hacker

Just a thought, When I use this type of solution, the biggest problem for me is remembering to emit the sessionID and any other parameters I need to persist.

If you're using CGI.pm and you have it generate the forms, a real easy hack is to override the different forms subs to include them automatically for you.

######################################
sub persistant_fields {
    my @fields = qw(username  sessionID);

    my $text = undef;

    foreach (@fields){
        $text.=input ({-name=>$_, -type=>'HIDDEN', -value=>param($_) }
+ )."\n" if param($_);
    }
    
    return $text;


}
######################################
sub form_ID{
         input ({-name=>'formID', -type=>'HIDDEN', -value=>substr(md5_
+hex(time.$$.rand()), 0, 32) } )
}
######################################
sub start_form {
    CGI::start_form(@_).form_ID().persistant_fields();
}
######################################
sub start_multipart_form {
    CGI::start_multipart_form(@_).form_ID().persistant_fields();
}
[download]



-Lee

"To be civilized is to deny one's nature."

Problem is people hitting reload after submit.

(aside from the problem that such a hide-the-button trick involves javascript, which everyone and their brother encourages fellow monks to shut javascript off while on PM)

I don't think javascript is necessary for the server to simply not emit the HTML tags that would denote the button. Straight Perl should be sufficient.

On the other hand, it's not the submit button that's the problem. As someone else points out, it's the refresh button provided by the browser itself that is at issue.

The solution is to disallow multiple distinct posts to an area by the same monk within a time window (something I'd like to see to prevent flooding), or to disallow root nodes from the same monk that have duplicate names (a solution I'd also like to see, since it makes for better searches when the list isn't populated by the same title over and over).

In any case, I don't think hiding submit is a good idea since often a post will be gummed up and require a quick fix. The lack of a submit button would make it hard to fix such an error.

Woah! Slow down cowboy, you have already submitted this comment 10 seconds ago!

Or something like that. I'm not sure how they do it(i've never looked at slashcode), or if it would be possible for the monastery, but it would solve the refresh button issues with posting.

--xPhase

UPDATE: I added in the rest of my thought, which, due to lack of caffine, I seem to have left out previously.

Easy, just include a unique id in a hidden field in the form.

Isn't the problem more the fact that people keep reloading the page they get after submitting, to check for comments (or for whatever reason) and in doing so keep submitting the same story? Same problem you get in the Chatterbox sometimes...

While this may be incompatible with the Everything architecture, but something i often do (this may be protocol-abuse :) ) is have the processing script redirect to the destination page rather than generating the destination page. This way if they reload they can't accidentally re-submit a form.

In fact, I generalise this to make ALL form submits, etc issue only a HTTP redirect to the response page.

Also the problem that can only be fixed reliably server side is, a user double clicks Submit.

On some browsers if you are quick enough the browser will dutifully submit the entire form twice.

A unique key or duplicate check is the only solution that doesn't rely on the client running JS or the like to prevent double clicking the Submit.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.