Hi, Janine,
As Chuck said, there are lots of ways of handling this. Perhaps the
following notes will make Chuck's first suggestion regarding
overriding validationFailedWithException in the WOComponent a little
more explicit. I took these notes from an article by Andrew Lindesay
in StepWise a while back.
If you would like the full (very helpful) article, it can be found at:
http://www.stepwise.com/Articles/Technical/2003-09-29.01.html
Here are my notes:
Retaining User Entered Invalid Data for Re-entry
Modify the WOComponent as follows:
1. Define a mutable dictionary in the component to hold invalid entries.
protected NSMutableDictionary invalidData = new
NSMutableDictionary();
2. Override the validation failed method to cache invalid results in
dictionary.
public void validationFailedWithException(Throwable exception,
Object value, String keyPath)
{
super.validationFailedWithException(exception, value, keyPath);
invalidData.setObjectForKey(value,keyPath);
}
3. Override valueForKeyPath in the WOComponent to prioritize return
of cached invalid data.
public Object valueForKeyPath(String keyPath)
{
Object invalidObj = invalidData.objectForKey(keyPath);
if (null != invalidObj)
return invalidObj;
return super.valueForKeyPath(keyPath);
}
4. Override awake method to refresh invalid data cache.
public void awake()
{
super.awake();
invalidData.removeAllObjects();
}
Hope this helps.
Regards,
Jerry
On Dec 9, 2005, at 2:39 PM, Chuck Hill wrote:
HI Janine,
On Dec 8, 2005, at 10:49 PM, [EMAIL PROTECTED] 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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/jerrywwalker%
40gmail.com
This email sent to [EMAIL PROTECTED]
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
[EMAIL PROTECTED]
203 278-4085 office
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
[EMAIL PROTECTED]
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
