Conceptual question about populating/validating values

[le...@mutzbraten.de]

Hi there,

I have a conceptual question about the population process for properties
inside Struts.

First of all a description:

I have a JSP which includes a text input field like this:

<html:text name="myForm" property="currentPerson.birthDate"/>

"currentPerson" is a Person-Object which has a birthDate-Attribute of type
java.util.Date (!).
This object is part of the myForm-Bean. 

I know about the alternative to have string values in my FormBean and set
the property of my object "by hand", but I don't like this !!

The Request-Processing now does the following:

1. RequestProcessor.processPopulate(...)
   2. RequestUtils.populate(...request)
      3. BeanUtils.populate(bean, properties)
      ...
      4. BeanUtils.setProperty(...)
         5. ConvertUtils.convert(...)
            6. PropertyUtils.setProperty(...)
            
6. RequestProcessor.processValidate(...)
..

In my example the string representing a date is converted into a
Date-Object in step 5 (ConvertUtils.convert())
I could use the sessions locale here for LOCALE-specific conversions and
set a default value in case the conversion failes.
I know about this !

Lets asume the following:
-> A user enters an invalid date 
-> conversion failes and the default value will be set as birthDate
-> the user gets the page back including an error message about an invalid
date
-> the date input field holds the default date now

BUT: What I would like the user to see is it's original text, not the
default value or anything else.

ANY IDEA, how to do this ? (Without having string variables to store the
form-values !)
Since I also would also like to specify a regexp-mask in the
validation.xml it looks to me, that the processValidate() is a bit too
late.

Thanks in advance,
Dirk









---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: Conceptual question about populating/validating values

[Ted Husted <hu...@apache.org>]

I'd agree with Edgar. Since ActionForms are a class rather than an 
interface, as it stands, you either have to live with the duplicate 
objects, or least two sets of properties, or go to other extremes. You 
can do things like use the ActionForms as an adaptor or facade for your 
business objects, or nest your business objects on the ActionForm, but 
that's no less work, and causes its own set of problems.

The other leading Java frameworks are WebWork, Maverick, JPublish, and 
Barracuda, if you care to have a look. After choosing Java itself, 
selecting an application framework and persistence layer are the most 
important decisions you will make. So, it's worth shopping around.

For harvesting form values, I've been playing with FormProc recently. It 
has a different approach than the Validator, in that it doesn't validate 
JavaBeans, it validated a list of input entries against a collection of 
field elements that comprise the form. Once the input for a field is 
validated, then it is converted and transferred to a target object (an 
arbitrary JavaBean or Map implementation).

One thing to note is that FormProc doesn't do a wholesale transfer. If a 
parameter does not correspond to a field element, it is not harvested. 
So, you don't have to worry about inappropriate properties being 
populated by a hostile client. Also, the target property (or entry) is 
only populated *after* it has been validated, so bad data is never 
tendered to good objects =:0)

Meanwhile, the original input is maintained on a separate List. So, when 
you go back to the page, you can redisplay the original (buffered) 
input, whether it was valid or not. (Well, I had to submit a patch for 
that one, to give the list a public accessor.)

I'm working on a FormProc extension for Maverick now and may try one for 
Struts next (by hooking into the reset method). This would let you 
define your form without subclassing a base ActionForm, much like the 
DynaActionForm.

-Ted.


lecker@mutzbraten.de wrote:

> Hi there,
> 
> I have a conceptual question about the population process for properties
> inside Struts.
> 
> First of all a description:
> 
> I have a JSP which includes a text input field like this:
> 
> <html:text name="myForm" property="currentPerson.birthDate"/>
> 
> "currentPerson" is a Person-Object which has a birthDate-Attribute of type
> java.util.Date (!).
> This object is part of the myForm-Bean. 
> 
> I know about the alternative to have string values in my FormBean and set
> the property of my object "by hand", but I don't like this !!
> 
> The Request-Processing now does the following:
> 
> 1. RequestProcessor.processPopulate(...)
>    2. RequestUtils.populate(...request)
>       3. BeanUtils.populate(bean, properties)
>       ...
>       4. BeanUtils.setProperty(...)
>          5. ConvertUtils.convert(...)
>             6. PropertyUtils.setProperty(...)
>             
> 6. RequestProcessor.processValidate(...)
> ..
> 
> In my example the string representing a date is converted into a
> Date-Object in step 5 (ConvertUtils.convert())
> I could use the sessions locale here for LOCALE-specific conversions and
> set a default value in case the conversion failes.
> I know about this !
> 
> Lets asume the following:
> -> A user enters an invalid date 
> -> conversion failes and the default value will be set as birthDate
> -> the user gets the page back including an error message about an invalid
> date
> -> the date input field holds the default date now
> 
> BUT: What I would like the user to see is it's original text, not the
> default value or anything else.
> 
> ANY IDEA, how to do this ? (Without having string variables to store the
> form-values !)
> Since I also would also like to specify a regexp-mask in the
> validation.xml it looks to me, that the processValidate() is a bit too
> late.
> 
> Thanks in advance,
> Dirk
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> 
> 

-- 
Ted Husted,
   Junit in Action  - <http://www.manning.com/massol/>,
   Struts in Action - <http://husted.com/struts/book.html>,
   JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org