ValidatingFormBean (Was: Re: AW: AW: ANNOUNCEMENT: New JAKARTA-STRUTSSubproject)

["Hutchison, Jeff" <jh...@inst.strykercorp.com>]

On Wed, 14 Jun 2000, Craig R. McClanahan wrote:

> "Hutchison, Jeff" wrote:
> 
> > [snip]
> > I agree, self-validating beans do sound cool.  I think the validate()
> > approach mentioned by Frank might be useful.  I'm reminded of two
> > different types of validation that Brett McLaughlin mentioned in a
> > presentation I saw at the O'Reilly Java conference earlier this year.
> >
> 
> As long as you call the validate() method *after* all the property setters,
> I'm fine with this.  That way, the form bean still faithfully represents the
> state of all the user input fields when you redisplay.

As long as you don't mess with the ActionServlet, you'll always satisfy
this contract, right?  If someone needs to override some default
controller behavior, they'll need to understand this.  Would it make sense
to utilize the GoF Template design pattern and build some hooks into the
process() method?  This might be a way to plug in some custom behavior
(like maybe authentication checking) while still enforcing basic
contractual stuff that the framework depends on (like all setters called
before validate).  Not sure if there are many interesting use cases for
this, just thinking out loud while our latitude for change is still
(relatively) large.
 
> There are going to be cases where validation like this is not necessary.
> How about if we have a new interface (ValidatingFormBean) that extends
> FormBean?  Then, the controller servlet can do an "instanceof" check to see
> if this behavior is required.
> 
> Returning the error messages that describe the problems has one interesting
> wrinkle in internationalized applications -- what language do you use?  To
> make this decision properly, the validate() method would need to know the
> current user's Locale and have access to an appropriate ResourceBundle or
> MessageResources object to grab the messages from.

> Given all of this, how about the following method signature:
> 
>     public String validate(Locale locale, MessageResources resources);
> 
> which would return a String containing the HTML (presumably) text you want
> to display with the errors in it, or null if there were no errors.  The
> controller servlet would call this method if it exists on the current form
> bean, and if it got a non-null resource you would save a request attribute
> and forward control to a JSP page identified in the mapping -- presumably
> the name of the input form page (we'd need to add this as a standard mapping
> property).

How about returning String[] and having the controlling servlet save
it as a the Action.ERROR_KEY request attribute?  That way the standard
"errors" custom tag can be used to display the validation errors.

> 
> Does that sound like a reasonable approach?

Yes.  Once the dust settles on the approach, I'd be eager to take a
swipe at it.

-- 
Jeff Hutchison <jh...@inst.strykercorp.com>
Stryker Instruments Kalamazoo, MI

Re: ValidatingFormBean (Was: Re: AW: AW: ANNOUNCEMENT: NewJAKARTA-STRUTSSubproject)

["Hutchison, Jeff" <jh...@inst.strykercorp.com>]

On Wed, 14 Jun 2000, Craig R. McClanahan wrote:

> "Craig R. McClanahan" wrote:

> I had forgotten that the <struts:errors> tag expects a String array
> of message keys, not actual message text.  Therefore, the validate()
> method should return String[] instead of String, and it doesn't need
> any arguments -- the internationalization stuff is handled within
> the errors tag.

Actually, I think the way you said it first was right.  The localized
message gets inserted in the array, not the message key.  For example,
in struts-example's LogonAction:

  if (user == null)
      errors.addElement(messages.getMessage(locale,
		        "error.password.mismatch"));

Although, I think I would like putting the error key in the array
instead.

-jh

-- 
Jeff Hutchison <jh...@inst.strykercorp.com>
Stryker Instruments Kalamazoo, MI

Re: ValidatingFormBean (Was: Re: AW: AW: ANNOUNCEMENT: NewJAKARTA-STRUTSSubproject)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

"Craig R. McClanahan" wrote:

> I agree with what to do with the result.  My only nit-pick is that I don't see the
> need for a String[] response.  If you are returning HTML that you want to have
> pretty-printed (if someone does a "view source"), you can always insert your own
> \r and \n characters.
>

Never mind.

I had forgotten that the <struts:errors> tag expects a String array of message keys,
not actual message text.  Therefore, the validate() method should return String[]
instead of String, and it doesn't need any arguments -- the internationalization stuff
is handled within the errors tag.

>
> Which of course means that the <struts:errors> tag should handle a single string
> attribute also ... I will fix that.
>

Just fixed this as well.  If you only have a single error, you can now save that as
the request attribute -- you don't have to package it as a String array if you don't
want to.

Craig

Re: ValidatingFormBean (Was: Re: AW: AW: ANNOUNCEMENT: NewJAKARTA-STRUTSSubproject)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

"Hutchison, Jeff" wrote:

> On Wed, 14 Jun 2000, Craig R. McClanahan wrote:
>
> > "Hutchison, Jeff" wrote:
> >
> > > [snip]
> > > I agree, self-validating beans do sound cool.  I think the validate()
> > > approach mentioned by Frank might be useful.  I'm reminded of two
> > > different types of validation that Brett McLaughlin mentioned in a
> > > presentation I saw at the O'Reilly Java conference earlier this year.
> > >
> >
> > As long as you call the validate() method *after* all the property setters,
> > I'm fine with this.  That way, the form bean still faithfully represents the
> > state of all the user input fields when you redisplay.
>
> As long as you don't mess with the ActionServlet, you'll always satisfy
> this contract, right?  If someone needs to override some default
> controller behavior, they'll need to understand this.  Would it make sense
> to utilize the GoF Template design pattern and build some hooks into the
> process() method?  This might be a way to plug in some custom behavior
> (like maybe authentication checking) while still enforcing basic
> contractual stuff that the framework depends on (like all setters called
> before validate).  Not sure if there are many interesting use cases for
> this, just thinking out loud while our latitude for change is still
> (relatively) large.
>

Sounds like it might be a reasonable thing to look at.  A very simple approach
might be to define "preprocess()" and "postprocess()" methods that are called
before and after "process()", and let you override these in a subclass.

Of course, there's always overriding process() itself, like this:

    public void process(.....) ... {

        ... do the "before" stuff ...
        super.process(request, response);
        ... do the "after" stuff ...

    }

which works just as well.  The only time this simple approach doesn't work is when
you want to intersperse your special processing code in between some of the things
that ActionServlet.process() normally does.

>
> > There are going to be cases where validation like this is not necessary.
> > How about if we have a new interface (ValidatingFormBean) that extends
> > FormBean?  Then, the controller servlet can do an "instanceof" check to see
> > if this behavior is required.
> >
> > Returning the error messages that describe the problems has one interesting
> > wrinkle in internationalized applications -- what language do you use?  To
> > make this decision properly, the validate() method would need to know the
> > current user's Locale and have access to an appropriate ResourceBundle or
> > MessageResources object to grab the messages from.
>
> > Given all of this, how about the following method signature:
> >
> >     public String validate(Locale locale, MessageResources resources);
> >
> > which would return a String containing the HTML (presumably) text you want
> > to display with the errors in it, or null if there were no errors.  The
> > controller servlet would call this method if it exists on the current form
> > bean, and if it got a non-null resource you would save a request attribute
> > and forward control to a JSP page identified in the mapping -- presumably
> > the name of the input form page (we'd need to add this as a standard mapping
> > property).
>
> How about returning String[] and having the controlling servlet save
> it as a the Action.ERROR_KEY request attribute?  That way the standard
> "errors" custom tag can be used to display the validation errors.
>

I agree with what to do with the result.  My only nit-pick is that I don't see the
need for a String[] response.  If you are returning HTML that you want to have
pretty-printed (if someone does a "view source"), you can always insert your own
\r and \n characters.

Which of course means that the <struts:errors> tag should handle a single string
attribute also ... I will fix that.

>
> >
> > Does that sound like a reasonable approach?
>
> Yes.  Once the dust settles on the approach, I'd be eager to take a
> swipe at it.
>
> --
> Jeff Hutchison <jh...@inst.strykercorp.com>
> Stryker Instruments Kalamazoo, MI

Craig