I *think* the other option is to put your form bean (& it's emebedded VO) in session scope (rather than request which you seems to have at the moment).
Doing this means that the unchanged values on your VO will remain unchanged (rather than being nulled). Paul -----Original Message----- From: Darren Hartford [mailto:[EMAIL PROTECTED] Sent: 03 October 2003 14:26 To: Struts Users Mailing List Subject: RE: newbie: Best Practice Struts/Value-Objects? To make sure I understand, the options so far are to: 1. Pass the full VO to the view, create the 15 other fields as hidden tags within the form, and then on submit Action create a blank VO and populate with the fields and send to the DB. 2. Pass the full VO to the view, get the 5 fields that are changed from the form, and then on submit Action re-create the original VO and simply change the 5 fields within that newly created original and pass that back to the DB. 3. Create specialized LightVO's that are only the field groupings that will be changed for that submit Action (and send the LightVO's back to the DB as-is with the changes from the form). With #1 I mentioned some concerns with maintanence but some good options came up on how to work around those. #3 seems the best approach for an environment that will be setup and not likely to change and the 'end result' for a good system (aka after there are NO more changes, and we know how often that is). But for my scenario/environment, of the options presented it seems #2 is the best combination for low-maintanence and flexibility to get started on a project and then as things settle down and performance becomes a motivator move to #3 (which is an easy migration path). Does this seem to correctly identify all the options of using Value-Objects with Struts? -D -----Original Message----- From: Menke, John [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 3:31 PM To: 'Struts Users Mailing List' Subject: RE: newbie: Best Practice Struts/Value-Objects? Maybe make what we call a displayBean in our app. It is not a VO as we view VO's to be more domain oriented. It's just for the front end. In your action create the display bean and set it on the form. Then in your action have logic to take values from displayBean and set them in the VO. We don't want our API to get crowded with view oriented objects so the displayBean is kept in the same package as the actions. VO's are more domain oriented and can go into API package. -jm -----Original Message----- From: Darren Hartford [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 2:20 PM To: Struts Users Mailing List Subject: RE: newbie: Best Practice Struts/Value-Objects? Hi John, Yeah, that is one (messy) solution to my problem. My concern is I would have to do add those 15 fields in every JSP page that sends the VO back, and if I have to make a change to the DB/VO, then go back over every JSP page again to make more changes. I'm trying to get to as low-maintanence as possible initially, even if it means sacrificing some performance by not using light-value-objects in the beginning. Can always make it faster after it is working correctly, right? ;-) I'm still lost as to how to handle Struts with Value Objects though.... -D -----Original Message----- From: Menke, John [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 12:16 PM To: 'Struts Users Mailing List' Subject: RE: newbie: Best Practice Struts/Value-Objects? you could use hidden variables on your jsp page to store the VO attributes you are not changing and keep your VO intact only changing the 5 fields -----Original Message----- From: Brian McSweeney [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 11:05 AM To: 'Struts Users Mailing List' Subject: RE: newbie: Best Practice Struts/Value-Objects? Hi Darren, I was under the impression that it works exactly the way you hope it does. Actually I'm pretty sure it does. Also what might be worth looking at ( I have to look at it myself ), is Light-value-objects where you only populate the initial value object with the 5 fields rather than the whole 20. This is obviously more optimal in terms of db queries. This is all pre-supposing you are using xdoclet and EJBs and xdoclet, which perhaps you are not. HTH, Brian -----Original Message----- From: Darren Hartford [mailto:[EMAIL PROTECTED] Sent: 02 October 2003 13:41 To: [EMAIL PROTECTED] Subject: newbie: Best Practice Struts/Value-Objects? 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] --------------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ************************************** Axios Email Confidentiality Footer Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet email messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my Company or employer unless otherwise indicated by an authorised representative independent of this message. WARNING: While Axios Systems Ltd takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Axios Systems Ltd grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
