Raible's Wiki: ValueObjectInForm

At line 1 changed 22 lines.

Recently I was discussing with Matt about where to put those special ""view"" get/set methods that are needed when a model value object has to be adapted to a form. At the same time were were discussing DynaActionForms vs. XDoclet generated ActionForms and I realized it was all related, so I will try to sum it up as best I can here.

~ [Mojavelinux]

When I first started developing with Struts (pre 1.0), I'd just have a simple form with a DTO (VO back then) as a getter/setter on my form. In the last year, I've changed to have a DTO and a Form, where the DTO has the true data types (Long, Date, etc) and the form has only Strings. After doing it both ways, it seems like the DTO as a getter/setter is really the better way

to go. I'm not trying to say it's the *right* way according to the design patterns, I'm just offering my $.02 from experience. I continue to do it the BeanUtils.copyProperties() way, but the projects I work on that do it the other way seem cleaner.

For an example of a DTO -> BeanUtils.copyProperties() -> Form, check out the following links:

DTO -> User.java (source: [http://tinyurl.com/emo7])

Conversion -> UserManagerImpl.java (source: [http://tinyurl.com/emof]

- see convert() method). This extends BaseManager ([http://tinyurl.com/emok]),

which registers custom converters. No DateConverter in this example,

but I've done it at my day job, so I know it's fairly easy.

Form -> UserForm.java (generated via XDoclet from User.java)

</p>

''from the [struts-user mailing list|http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg69836.html].''

~ [MattRaible]

--> Please see [DTOInForm]

Raible's Wiki

AppFuse

Other Applications

ValueObjectInForm