silverorange labs

Comments

Comments are locked. No additional comments may be posted.

Jevon -


It may not be what you are looking for, but I use and onclick() event to fire a disable set on the submit button. It greys out and can't be hit twice. I haven't checked fully, but haven't noticed any cross-browser issues. I'll get the code when I am at the office tommorow and post it, it's just one short javascript="" line.

Steven Garrity -

Jevon, that is useful, but as you suggest, it's a slightly different issue. Disabling the submit button after the onClick will prevent a second post while the original page is still there. However, something like we've implemented here is necessary to keep the double post from happening when someone reloads the page after they've made their post.

Jevon -

Err, In writing that response, I knew there was something else. Yes, I tend to use less involved dupe-checking in such situations as well, but not as often as I should.

Steven Perry -

Disabling the submit button is usually a bad idea. Cause what happens if after clicking submit, the form doesn't actually get processed? There's no way for them to retry without refreshing the page, losing what they've already written.

What I usually do is just process the form data, and then forward to the original page, instead of loading it with the same script. This doesn't stop the double-posts that result from a user clicking the submit button over and over, but allows them to refresh.

CMax -

md5 checksum is a most reliable (& X-platform) method for file check.

Steven Perry -

I think I found a small flaw in the md5 uniqueid technique, although it may be a little overly picky.

What if a user submits a response, and then after reading it, realizes they left something out. Instead of using the form on the current page, they may go back, and rewrite the one they just submitted to contain the stuff they forgot, and resubmit... it'll be ignored.

Peter Rukavina -

Wouldn't the situation Steven described be a candidate for throwing out the original response and replacing it with the newly edited version?

Joao Prado Maia -

How about just adding a UNIQUE index on those fields ? That way you can just check the error returned by the database server and show a pretty message to the user. Storing a md5/random key seems overkill for something that the server should be taking care of.

Just my 2 cents here.

nathan -

Joao: There is a unique index field but it is auto-generated by the database when a new record is inserted. Since the original form is generated before any database activity, it can not contain that unique ID.

Steven Perry & Peter: I agree. When the key matches an existing record it makes more sense to update with the new content than it does to ignore it. That will still solve the double post problem as well as allow use of the back button to fix a post you just made.

Steven Garrity -

Thanks for the feedback guys. As for replacing the post with the updated form contents as mentioned above (by Steve Perry, Peter, and Nathan) – this has a few drawbacks. First, I can’t imagine anyone expecting that behaviour. More importantly though, you get into the situation of editing content in an active discussion. For example, do you put the date/time of the original post, or do you update it with the date/time of the reload? If there have been other comments since the original, you could have a comment with a data/time after a comment that follows it. Also, as for editing comments – I almost never do this – even where there are mistakes. When people reply, they often reference existing comments (and sometimes they specifically mention the mistakes). As soon as you change that, any replies that may follow lose their context.

Stephen DesRoches -

This maybe starting to get too complicated for a simple reply system. If we start to assume that a user may go back to edit a post after they already see it posted on the page, we could also assume they would go back to add a second reply. If that is the case they would be over-writing their first.

I don't think any other blog system has this behavior so wouldn't the preview be good enough for your last chance to edit?

Depending on how long they wait to go back and edit, once a post is made anybody using rss readers will see the original post. I don't think the readers will notice the text being updated.

nathan -

"can’t imagine anyone expecting that behaviour"

I think it is very natural behaviour. I find myself trying to go back, but then remember the technical reasons why it won't work. I'd be willing to bet that non-technical users try to use the back button to edit a post all the time. Isn't breaking the back button functionality one of the classic user interface mistakes?

That said, I do agree with the potential problems of editing live data. You could mitigate the problem placing a time limit on it of a few minutes, but this wouldn't be ideal either.

Steven Perry -

Maybe compare the first sentence of the newly submitted data to the already stored data. If they match, assume it's the same post, or an updated one, and replace the old one. If it's different, assume it's a new post, generate a new unique id, and store it.

Stephen is right though, this is getting a little overly complicated for something as simple as a double-post. I think it's just one of those things you kinda have to live with.

Brian -

Sorry if someone's suggested this already. I'm assuming it's because people are reloading after posting a reply, then clicking "ok" to re-send the form data. Why not post to an intermediate page, which then forwards the poster back to whence they came, ala Infopop style? Carry the current page along as a variable, and when the db updating is done, send the poster back to the page.

Of course you could get fancy and allow editing of posts, provided the user has the Remember Me cookie selected.

Isaac Grant -

Okay - turns out we were operating on some false assumptions.

We had avoided doing the form processing, and then forwarding back to the same page with a header, as we want to return to the anchor on the page. Testing on a previous system we built had lead us to believe you couldn't forward to an anchor. Turns out we didn't really do enough testing, and this is only true when redirecting from a form with <span class="code">enctype="multipart/form-data"</span>, and only true of IE flavours on the PC.

So our solution has been adapted to do the form processing, then redirect to the page. Currently the md5 key still exists, and still checks, to prevent double posting by hitting the back button, and the create button again. But this functionality is currently being debated. Does it make sense to get rid of it all together? Or perhaps to make it edit the reply like its been suggested?

Michael -

in response to the issue of "non-technical users"....

That arguement is NEVER valid.
it equates to saying "If people can't operate a vechicle properly, let's change the nations highway system to accomodate them"

If they are NON_TECHNICAL, then educate them, don't try to change an existing system in order to accomodate them.

Whoever posted it originally is obviously a Democrat.

Michael -

Looks like I was still able to click back and get a double-post out of it.

Michael -

How come nobody has made a post here for more than a year?

Craig -

Been looking at this problem myself and the only full solution I found was what Michael Jouravlev wrote called Redirect After Post. Using the PRG pattern (POST->REDIRECT->GET) you will be able to prevent an HTML form from submitting the information twice either by clicking the button or refreshing the page.

You can read the 11 page article here.

http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost

It solves the problem in more ways than one.