Could you not, then, consider ActionForms and DynaActionForms xfer objects?
Mark -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED] 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. -Ted. 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 fields. > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
