Ted Husted ([EMAIL PROTECTED]) wrote: > 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.
I agree with all of what Ted said as he certainly summed it up very well. I want to append an idea of how you can update a portion of your fields without having to put the DTO in session or push all the values to hidden fields. In your "setup" action, query the employee and obtain a DTO. At this point, populate the form bean (or just push the DTO to the view) with a form containing the fields of interest and one hidden field for your employee ID or unique identifier (or save the ID in session). Then, on the "save" form, query the DB for the employee based on the employee ID (you can protect this in terms of security with a token or other such measure) then use beanutils to copy the results of the form to that DTO and save the DTO. In short, instead of keeping around the DTO, just keep around a key to get to that DTO, whether in a hidden field or the session. Then, you can call up the DTO at any point, update it and push it back to the persistence layer when you want to save it. The nice part about this technique is that your action forms and DTOs don't even have to align, since you draw what you need out of the form and push it into your DTO to be saved. Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, <[EMAIL PROTECTED]> http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Real programmers just hate to get up in the morning, and contrary to Ordinary People, they're in better shape as it gets closer to nighttime. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
