I would say this is reasonable. I get the impression this is the
general approach currently being taken by most Struts developers. There
are two drawbacks I can think of to consider before coming to a final
decision:
1) Unless the code is being generated, there is more manual
labour involved in coding the two bean classes and the
code that maps them one to the other (and this has
to be updated when changes to the bean are made). [You can use
the Struts BeanUtils class (see BeanUtils.populate and
BeanUtils.describe methods in the api:
http://jakarta.apache.org/struts/doc-1.0.2/api/index.html)
as a basis for a way to automatically
map one type of bean to another type of bean.]
2) Performance penalty for copying a list of result beans to
a list of form beans.
> 1) get Collection of EmployeeBeans from DB
> 2) *Extra step now will be a method that now returns a Collection
> that converts the above Collecion into EmployeeForm beans
> collection.
> 3) Now use the EmployeeForm bean collection for display.
>
> Then possibly same thing for inputing..
> 1) user inputs form
> 2) form bean passed to a method which would covert it to
> EmployeeBean (obviously having first been validated)
> 3) Now EmployeeBean is used to populate DB.
>
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
