Re: Reporting form errors to the user
Re: Reporting form errors to the user
- Subject: Re: Reporting form errors to the user
- From: Arturo Pérez <email@hidden>
- Date: Fri, 9 Dec 2005 22:27:11 -0500
On Dec 9, 2005, at 2:39 PM, Chuck Hill wrote:
HI Janine,
On Dec 8, 2005, at 10:49 PM, email@hidden wrote:
In my day job I build websites in a scripted environment. The
"conventional wisdom" on handling form validation errors goes like
this: the user goes to /foo and fills in the form. When they hit
the submit button, they are routed back to /foo again, except this
time it's a POST instead of a GET. The code within /foo is a giant
if-statement - if the request is a GET, set up the input form. If
it's a POST, validate the user's input and if there are errors,
redisplay the form with the data filled in and error messages beside
each field with problems. This is considered better than the
alternative of sending the user to a second script which would then
have to contain duplicate code to set up the form again if there were
errors.
Um, "Ick!" is the first thing that comes to mind.
Well, lots of things came to mind for me. "Ick!" wouldn't really
register on the scale of what I was thinking :-)
I was working on one of these monstrosities today and it got me
wondering how this is handled in WO. I looked at all of my WO books,
but I didn't see anything that covered this. Could someone give an
overview (at a newbie level) of how this is done?
<Chuck's excellent answer elided>
Chuck
Another suggestion that you'll see often in the WO world.
Rather than any sort of conditional logic, place an error
message/messageID in a Dictionary. Put a WOString next to every field
to display the errors and bind them to the Dictionary.someID where
someID matches the key of the error message in the Dictionary. If
there is no message under that key it conveniently evaluates to an
empty string (effectively). Very simple and no conditional logic on
the page required.
At save time, etc, check for any values in the Dictionary. If any are
present don't do anything just return the page.
messageIDs rather than error messages are nice because then one can use
stringForKey methods to return nice, user-friendly messages.
My complaint is that EOF sometimes goes first and it puts less
localizable messages in (e.g. "first name cannot be NULL"). Is there
any way to intercept those?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden