Seems to me that the issue is in how you go about hitting the database with your TO.
Basically I'm +1 on "solution #2". Typically the only hidden html field I use routinely is for the key of the record. If you put all of the "not being updated fields" into the html, youre creating potential problems. 1) If you have a page which will update field A, but have field B as hidden, and while the user on this screen is on the phone, someone else updates field B, when the user saves his record, the other guy's field B will be overwritten. 2) People can potentially just view source on the html and discover how to directly manipulate the database in ways you may or may not want. > -----Original Message----- > From: Leandro Melo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 25, 2004 10:18 AM > To: Struts Users Mailing List > Subject: Re: ActionForm and Transfer Object > > > Rick, > i agree with you, i also use BeanUtils to populate my > forms. > But, this doesn't go far way from having your > ActionForms dependent on your TOs (or CustomTOs, > doesn' t matter). > As Sebastian said, i've heard a lot that TOs should > mirror or shouldn't be coupled to your ActionForms, > but i really don't how it's possible to build a very > modular architecture without this coupling. > > > > > --- Rick Reumann <[EMAIL PROTECTED]> escreveu: > > Sebastian Ho wrote: > > > > > > > > Say I retrieve a TO from database and convert it > > into a actionForm for > > > display. In this case I have 4 fields for my > > actionForm but 10 in my TO. > > > (6 are not needed for display). A user updates the > > 4 fields and the > > > action convert those into TO. In this case, the > > other 6 fields will be > > > reset to null(or empty) in my database! > > > > > > To prevent this, I actually need to use hidden > > fields in my JSP or some > > > other ugly solutions in my Action class. They are > > still dependent on > > > each others afterall. > > > > You can handle this several ways... > > > > For example, one solution is you create a > > TransferObject that refers to > > only the fields you care about - in this case the 4 > > fields you > > mentioned. So your call to the business layer would > > return that > > TransferObject and you could then convert that > > easily to your form > > (using BeanUtils). Then going back the other way > > your business layer > > would take as an arguemnt the same type of > > TransferObject. > > > > I actually don't prefer the above, though, because > > say later on you > > decide you want to add another field to your form > > now your backend has > > to worry about handling a new object with different > > fields. > > > > I think the best solution is to simply make another > > call to get back the > > initial TO from the db, then simply use BeanUtils to > > populate that TO > > with the form fields. It will only set the fields in > > which it has the > > same names for so your other data will be fine. > > > > So it looks like... > > > > TransferObject to = > > BackendEnd.getMyTransferObject(..); > > MyForm myForm = (MyForm)form; > > BeanUtils.copyProperties( to, myForm); > > BackEnd.doUpdate( to ); > > > > Pretty simple I think. Just make sure your > > ActionForm doesn't contain > > properties that you don't care about editing > > otherwise it will > > over-write the TO properties. If the JSP form is > > going to be very > > dyanmic, as in it will sometimes have some > > properties and sometimes have > > others, then you will have to use more complex > > 'tricks' such as using > > hidden variables.. or I'd just prefer to manually > > set the TO fields in > > the Action. > > > > -- > > Rick > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > _______________________________________________________ > Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! > http://br.acesso.yahoo.com/ > > --------------------------------------------------------------------- > 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]
