struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Galbreath" <>
Subject RE: newbie: Best Practice Struts/Value-Objects?
Date Thu, 02 Oct 2003 20:21:28 GMT
Could you not, then, consider ActionForms and DynaActionForms xfer objects?


-----Original Message-----
From: Ted Husted []
Sent: Thursday, October 02, 2003 2:42 PM
To: Struts Users Mailing List
Subject: Re: newbie: Best Practice Struts/Value-Objects?

Value Objects, also called Transfer Objects, are a design pattern. The
idea is that you can minimize the calls to the business tier by
collecting all the data you might need at once and submitting it as a
batch. (Opposed to, say, updating a form a line a time.) The properties
on the Transfer Object might be used by more than one business
component, but you collect them all together to minimize the number of
trips to the business layer.

The ActionForms are a type of Transfer Object. They transfer data
between a HTML form on the presentation layer to the Action on the
controller layer. (But most people would say they should not travel past
the Action.)

Many people also use Transfer Objects on the business layer, and often
the ActionForms and their Transfer Objects will look alot alike.
(Annoyingly so, some might say.) It's commonplace for someone to collect
what they need on an ActionForm and then copy all that over to a
Transfer Object, for submittal to the business layer. Sometimes people
will even nest a Transfer Object on a ActionForm. Another approach is to
have the ActionForm implement the Transfer Object's interface.

If your Transfer Objects and ActionForms share the same protocol (use
the same propert names), you can also pass your Transfer Object directly
to the HTML page. The HTML form tag doesn't care if you use an
ActionForm to populate a form or not, so long as the properties match.

If you kept your ActionForm in session scope, then you could just expose
five fields and keep the others intact. Just watch the that your reset
method doesn't blank them out.

Without using session scope (or a cookie), there is no clean way to
retain the fields without writing them out on the page somehow. One
trick is to use a method that will spit out whatever hidden fields you
need and then just call that using bean:write.

For this use-case, another approach would be to create a more finely
grained business layer. If you only need to update five fields, then you
should be able to update only those five fields. So you would have
another database query that set those five fields, but left the others
alone. The others may exist on the Transfer Object, but the other
database query can just ignore those.


Darren Hartford wrote:
> Hi all!
> Been working with struts and value-objects, and I am beginning to
understand the power of these two in combination. I did however run into a
snag that may be either on purpose or just ignorance on my part.
> If I pass a 20-field value-object to an ActionForm (let's say an
EmployeeVO), and I only show the employee's name and address for editing
(only 5 or so fields).  They make the necessary changes and submit the form.
What I understand is the form will populate a NEW EmployeeVO and not make
the changes to the original EmployeeVO, thereby creating an EmployeeVO
populated only from the 5 fields on the form and nulling the other 15
> I was hoping to take an existing Value-Object, only make necessary changes
from the submitted form (i.e. 0-5 changed fields and the other 15 stay the
way they are), and then re-submit the Value-Object for updating the DB, but
that does not seem possible.  Am I doing something wrong and/or
mis-understanding the best utilization of Value-Objects with Struts?  Again,
I'm a newbie so any pointers, help, or examples would be great!
> thanky in advance!
> -D
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ted Husted,
   Junit in Action  - <>,
   Struts in Action - <>,
   JSP Site Design  - <>.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message