Re: Reporting form errors to the user
Re: Reporting form errors to the user
- Subject: Re: Reporting form errors to the user
- From: Chuck Hill <email@hidden>
- Date: Fri, 9 Dec 2005 11:39:04 -0800
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.
I have always hated this scenario; the files are large and
unwieldy and the if blocks are sometimes so big that it's possible
to try to debug the wrong one, wasting lots of time.
Yes, "Ick!". I was correct. :-)
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?
Ah, Grasshopper. When you are able to find the one, right, true way
of doing this you will be ready to leave us. Until then, I will
offer some advice.
i.e. There are lots of ways of handling this. What I have been doing
lately is to use validationFailedWithException in the components to
catch the validation errors (also need to handle saveChanges if you
call that from a component). This method simply asks the page (via
context().page() to record the error is a dictionary it maintains
under a key that can be reproduced. context().elementID() works well
or you can use the keypath if this is on one page. The unique key
really depends on what is on the page, if there are repetitions,
etc. This all happens during the takeValues phase.
In invokeAction, I check for valiation errors registered at the page
level and don't perform the action (e.g. save) if there are any.
During appendToResponse, conditionals are bound to a method that
returns the value for the key from this dictionary. If there is an
error for that specific input, the conditional evaluates to true and
the error message is displayed.
This all works much better in code (though not so pretty in
WOBuilder) if you make a component that wraps say a WOTextField,
WOConditional, and WOString so that all of this registration and
checking for validation messages is done once and the component can
just be dropped on a page.
Chuck
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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