• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Reporting form errors to the user
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reporting form errors to the user


  • Subject: Re: Reporting form errors to the user
  • From: "Jerry W. Walker" <email@hidden>
  • Date: Fri, 9 Dec 2005 15:50:35 -0500

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@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:
40gmail.com


This email sent to email@hidden


--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial Strength Internet Enabled Systems


    email@hidden
    203 278-4085        office






--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial Strength Internet Enabled Systems


    email@hidden
    203 278-4085        office



_______________________________________________
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


References: 
 >Reporting form errors to the user (From: email@hidden)
 >Re: Reporting form errors to the user (From: Chuck Hill <email@hidden>)

  • Prev by Date: Workaround: Deploy 5.3.1 on Other Platforms
  • Next by Date: Re: Workaround: Deploy 5.3.1 on Other Platforms
  • Previous by thread: Re: Reporting form errors to the user
  • Next by thread: Re: Reporting form errors to the user
  • Index(es):
    • Date
    • Thread