Here's a posting from the Struts JGuru forum http://jguru.com/forums/Struts
that I thought might make for an interesting discussion. David Hardy writes: > We have a form with 50 sets of 4 fields, representing > an address object. The form-bean will be used to handle > the fields contained in this form. > Issue #1: Is there anything specified in the contract or > reasoning saying that the fields in the form-bean need to > be of a certain type, specifically String. The desire is > to populate a hashtable of objects representing the 4 > fields making up the address, therein not having String > objects for each field, but having the set's and get's > access the hashtable for them. Along with this alternate > storage could be utilities for accessing the hashtable, > which would be adding extra functionality to the bean. Is > this considered putting too much logic in the bean? I am > curious whether it is "acceptable" or "good practice" to > change the bean to do more than just its conventional > setting and getting to basic String objects, in attempt > to have more usable objects to deal with. > Issue #2: Once you have this object full of your data, > what stops you from passing this fully populated bean to > the back end vice having to create essentially a duplicate > object? What would be the difference between the objects > other than they belong to their own 'mvc' space. > Any insight would be greatly appreciated. These issues are > understood somewhat in theory, but I am lacking concrete > reasoning. > Thanks, > David
