The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Where to submit?

A spin-off of http://discuss.joelonsoftware.com/default.asp?joel.3.421171.12

The question is, do you submit a form to the same URL or to a different URL?

I'd say for many applications you can submit to the same URL safely.

However, for forum systems I've found submitting to the same URL is a bad practice.  For example, if you have a reply-form at the bottom of a list of comments (think wordpress) I always submit to a different URL and redirect back to the comment page, shoving any error messages into the users session.  Otherwise, if the user hits refresh or wanders off and hits "back" they might double post by mistake.  I've used the same practice for for credit card forms or any other place where the user/browser might double-submit.

I'm curious as to how others handle form submittion submittion in their apps.
Cory R. King
Wednesday, November 29, 2006
 
 
For me, the rule of thumb seems to be whether the action requires some sort of explicit aknowledgement.

If I'm just adding data to a table and I can immediately see the effects of the change (the page is redrawn with the new table), then I submit it back to itself as it's easier to synchronize changes to input/output when they're together. Acknowledgement of a successful insert is implied and reflected in the data table itself.

If I'm sending email to someone through a web form, the general expectation is that there will be a "thank you" page. You however wouldn't get the email input form back unless you explicitly ask for it. In this scenario, splitting it across two files helps reinforce the one way nature of the relationship.
TheDavid
Wednesday, November 29, 2006
 
 
"I always submit to a different URL and redirect back to the comment page, shoving any error messages into the users session."

Using the session for error messages is definately bad form.  (If I don't have cookies enabled then I don't get any error messages?)

I'd submit to the same page and if successful then issue a redirect to the same page.  Solves all the issues, has the same number of redirects, and no problem with refresh or back.

"I'm curious as to how others handle form submittion submittion in their apps."

I *always* submit back to the original page except in a few small cases.  For example, I have a small search form on every page and that always submits to the search page.  Any errors can be handled on that page.
Almost H. Anonymous Send private email
Wednesday, November 29, 2006
 
 
"Using the session for error messages is definately bad form."

How else do you propose I maintain state between pages?  I'm not talking about storing the message in a cookie, only in whatever I'm using for a session handler.  Even if you redirect to the same page, you'll still have to maintain state somehow.

"(If I don't have cookies enabled then I don't get any error messages?)"

I'll degrade nicely for those without javascript.  The only "browser" that doesn't store cookies are search engines.  Search engines don't submit forms.
Cory R. King
Wednesday, November 29, 2006
 
 
"If I'm just adding data to a table and I can immediately see the effects of the change (the page is redrawn with the new table), then I submit it back to itself as it's easier to synchronize changes to input/output when they're together."

How to you handle when a user refreshes the page?  This is the problem I've found - the browser throws a nice "Submit the POST data again?" message.  If they hit yes, you get a double submittion.  If they hit no, then they don't get an updated view.
Cory R. King
Wednesday, November 29, 2006
 
 
"How else do you propose I maintain state between pages?"

The post back.

"I'm not talking about storing the message in a cookie, only in whatever I'm using for a session handler."

Sessions are managed by cookies.  No cookies, no session.

"Even if you redirect to the same page, you'll still have to maintain state somehow."

No, you only redirect if there are no errors (thus no need  for state).  If there are errors, you redraw the page with those errors.  There's no need to maintain any state because you are directly drawing the page as a result of the form.

"The only "browser" that doesn't store cookies are search engines."

Users can turn off cookies.  There's even a extension for Firefox that disallows all cookies except for those sites in a whitelist.  Users not accepting random cookies is always a possibility.
Almost H. Anonymous Send private email
Wednesday, November 29, 2006
 
 
Of course, the real reason for not maintaining state in the session is if I'm browsing your site with multiple tabs open.  I'm going to get some pretty weird results if the state from one tab is affecting my browsing in the other tab.
Almost H. Anonymous Send private email
Wednesday, November 29, 2006
 
 
Duh.  I get it.  For a second I thought you would submit and actually do a 302-redirect back to the page again.  I use your technique all the time, it is kind of a no-brainer. :-)

The only case I've found it breaks down is on comment pages that have a reply-form at the bottom or the "only hit this button once" type pages.  In those cases, I will submit to a new URL, process the data, shove any results into the session, and redirect elseware to display.  I've yet to find a better way to keep the browser from submitting again.

Your "multiple tab open" case is interesting.  I'm running through how several tabs open would break things.  If it did break, I'm wondering how to fix for your case while keeping the number of double-submissions to a minimum (some token passing?).  Would it even be worth fixing?
Cory R. King
Wednesday, November 29, 2006
 
 
"For a second I thought you would submit and actually do a 302-redirect back to the page again."

That's what I *am* suggesting..  *but* you only do the redirect part in the case that there are no errors.  That way you still get all the benefits of the redirect (refresh doesn't resubmit, back button works) and all benefits of the page submitting to itself.
Almost H. Anonymous Send private email
Wednesday, November 29, 2006
 
 
Interesting.  Why didn't I ever think of that. 

Good sir, I like your style.
Cory R. King
Wednesday, November 29, 2006
 
 
Re: detecting double submission

On display of the page to be submitted, the server populates a hidden field with a unique id.

On submission, check if the unique key has already been processed (e.g., has been stored in a database table)
Mike S. Send private email
Wednesday, November 29, 2006
 
 
That begs the question - how do you make a generic library that you can use to inject such tokens (or CAPTCHA images for that matter)?

Who is responsible for inserting the HTML required for the token? 

Who is responsible for knowing the name of the form field? 

Does the theoretical "check_token()" require you to pass in the value of the field, or do you let the library deal with it and all you worry about is the result.

If the library is responsible for getting the parameter, how to you avoid field name collisions?

For all questions, if it matters, assume your framework provides some kind of template system.
Cory R. King
Wednesday, November 29, 2006
 
 
"how do you make a generic library that you can use to inject such tokens (or CAPTCHA images for that matter)?"

Well these tokens a bit different from CAPTCHAs because they need to be stored in the database.  They cross all the layers.  You don't want to hide that behind your UI framework when you have to pass it on to your database.

So I think the best way to handle this sort of thing is manually.

"If the library is responsible for getting the parameter, how to you avoid field name collisions?"

Use a prefix (I use two underscores) and then disallow that prefix for all regular field names.
Almost H. Anonymous Send private email
Wednesday, November 29, 2006
 
 
The technique I use for FruitShow (click my link) is not to use a unique key stored in the form.  Instead, the forum stores an MD5 hash of the entire message in the row.  Whenever a new post is made, an MD5 hash is taken of the new message and the database is checked for recent additions of a message with the same hash.  If one is found, then the new message isn't saved.

This isn't quite as good, perhaps, as using a unique key in the form but it has the advantage of being completely abstracted away from UI.  The UI doesn't even know this is happening.
Almost H. Anonymous Send private email
Wednesday, November 29, 2006
 
 
Holy crap... that is a sweet idea.  I assume you make it unique for the user + the thread + the md5, right?

I do think there is a way you can abstract captchas.  Some library/class that returns HTML you can embed.  Later you can call the same library/class and it will automatically check the against the parameters and just lets you know if life is groovy or not.

My thinking is that as long as you properly mark up the generated HTML, you can style it with CSS based on whatever <div id=''> it happens to sit in.
Cory R. King
Wednesday, November 29, 2006
 
 
"I assume you make it unique for the user + the thread + the md5, right?"

Yup.  You can actually check it the source code (PHP), FruitShow is open source and available on SourceForge.

"I do think there is a way you can abstract captchas."

Most likely.  I think there are several captcha libraries available for just about every platform.
Almost H. Anonymous Send private email
Wednesday, November 29, 2006
 
 
At least in perl land, the most any captcha library I've seen do is generate the image.  It is up to the caller to take that image and do something with it.
Cory R. King
Wednesday, November 29, 2006
 
 
I'll take a look.  I've modeled this place on my own setup too (http://www.photographica.org/forums/photo_feed)

"License: BSD License " - http://sourceforge.net/projects/fruitshow

Thank you.
Cory R. King
Wednesday, November 29, 2006
 
 
"Sessions are managed by cookies.  No cookies, no session."

You sure can have sessions without cookies.
Manon Send private email
Wednesday, November 29, 2006
 
 
"How to you handle when a user refreshes the page?"

It varies from application to application, but there's realistically only four scenarios:

1) Sometimes you do want to add the data again.

2) Sometimes you want to insert the data if it doesn't exist, and update the data in place if it does exist.

3) Sometimes (rarely), you do want to inform the user that the data already exists and give them the option of changing it.

4) Sometimes the user goofs. With a little bit of clever coding and a politely worded error message, this essentially becomes option 3.

Notice that all of these scenarios exist to some degree even if the form action is a separate page. (What happens if you put the database call in the same page as the acknowledgement page instead of redirecting from the database insert to the acknowledgement?)

I generally loop back into the same page because if I have to change a form variable name, say from USERNAME to LOGINNAME, I can just do a search and replace in that one single file and not worry about breaking some other form/action that also uses USERNAME.
TheDavid
Wednesday, November 29, 2006
 
 
"Users can turn off cookies.  There's even a extension for Firefox that disallows all cookies except for those sites in a whitelist.  Users not accepting random cookies is always a possibility."

What extension?  That is standard functionality in Firefox 2.0, or am I misunderstanding?

Me?  Accept candy from strangers?

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Wednesday, November 29, 2006
 
 
"That is standard functionality in Firefox 2.0, or am I misunderstanding?"

Is it?  I'm still on 1.5.
Almost H. Anonymous Send private email
Wednesday, November 29, 2006
 
 
"That is standard functionality in Firefox 2.0, or am I misunderstanding?"

'Is it?  I'm still on 1.5.'

Wasn't it on 1.5, too?  We may be talking past each other on this.  What do you mean by it?  I am referring to "Accept cookies from sites" checkbox and the "Exceptions..." button in 2.0.  In 1.5, it was about the same, no?

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Thursday, November 30, 2006
 
 
"Wasn't it on 1.5, too?"

*Opens Options...*

Yup, it's in there in 1.5. 

I never noticed that before.  It's not terribly useful in that form, I don't always want to be heading into the options dialog to add or remove a site from the cookie whitelist.

There is, however, an extension that lets you control whether or not cookies are enabled from the status bar (click to enable / click to disable).  Probably also has the ability to add/remove sites from the whitelist perminently too.
Almost H. Anonymous Send private email
Thursday, November 30, 2006
 
 
"There is, however, an extension that lets you control whether or not cookies are enabled from the status bar (click to enable / click to disable).  Probably also has the ability to add/remove sites from the whitelist perminently too."

Please give the details of how to get it.

I would love to be asked whether to allow cookies.  I used to have that with CookiePal.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Thursday, November 30, 2006
 
 
Almost H. Anonymous Send private email
Friday, December 01, 2006
 
 
Thank you for the link.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Friday, December 01, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz