Re[2]: Proposed feature: Bean property transformations

[Oleg V Alexeev <go...@penza.net>]

Hello Ted,

Saturday, June 02, 2001, 1:30:00 AM, you wrote:

TH> "Harris, Andrew S" wrote:
>> A component would be able to hold a text value and a data value. The text
>> value could hold the value entered by the user, prior to validation, then
>> this could be played back to the user if validation failed on that
>> component. If validation succeeded, the data value would be updated, then
>> the text value would be replaced by the formatted value, using the data
>> value and the formatter.

TH> This is a good design pattern, and one we can use with Struts today. In
TH> the ActionForm bean, define two properties, one for the text value and
TH> one for the data value. If validation succeeds, convert the text value
TH> to the data value, and (optionally) update the text value to match your
TH> preferred formatting. 

TH> Though, with a general conversion/transformation package, we would
TH> really only need to store the desired data value since we could
TH> transform it again later when the value was accessed for presentation,
TH> perhaps via a bean:writeTransform tag.

What reason to store text values and data values in ActionForm? I
think that more flexible approach is to use ActionForm with text only
fields and data bean with native types, not String. In this case we
can name all corresponded fields in data bean with same names as for
ActionForm and use convert methods under it, for example, or use
another convert methods.
 We can convert text values to/from with one of the ways -
 1. Perform conversion of all fields in some method in ActionForm, for
    example import/export.
 2. Make it in every setter/getter.
 3. Write special helper class to perform conversion - in this case
    more flexible approach can be used - one helper can handle
    multiple sources and targets.

-- 
Best regards,
 Oleg                            mailto:gonza@penza.net

Re: Proposed feature: Bean property transformations

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

I agree. 

The primary fields on an ActionForm must be Strings, ActionForms should
not be used to store persistent data, and the beans used to store
persistent data should use appropriate types. 

The peristent data beans should not have to worry about data
conversions, and so that task should be performed by a helper object.

But encapsulating the helper object within the ActionForm can be a valid
approach, since converting the String to a native type may be considered
part of the initial validation. Once this is done, the persistent data
bean can call a getPropertyInt or getPropertyDate method to retrieve the
native Property type (and then perhaps perform any business logic
validations).

It's just a matter of whether you prefer converting the data in the
Action or in the ActionForm validation method. A reuseable helper class
could be implemented in either case.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/


Oleg V Alexeev wrote:
> What reason to store text values and data values in ActionForm? I
> think that more flexible approach is to use ActionForm with text only
> fields and data bean with native types, not String. In this case we
> can name all corresponded fields in data bean with same names as for
> ActionForm and use convert methods under it, for example, or use
> another convert methods.
>  We can convert text values to/from with one of the ways -
>  1. Perform conversion of all fields in some method in ActionForm, for
>     example import/export.
>  2. Make it in every setter/getter.
>  3. Write special helper class to perform conversion - in this case
>     more flexible approach can be used - one helper can handle
>     multiple sources and targets.
> 
> --
> Best regards,
>  Oleg                            mailto:gonza@penza.net