Thanks to all, for gliding me back to the light. Jim, you were right I was over engineering it. I'll put down the oil, screwdriver and jackhammer then digest Rick's suggestions.
again thanks, Shed > -----Original Message----- > From: Rick Reumann [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 12, 2004 12:05 PM > To: Struts Users Mailing List > Subject: Re: Multiple forms in one JSP + one Action > > > Hollaway, Shedrick CIV (TRFKB C600) wrote: > > > Rick, my apologies for being unclear here, html:text is > html-el:text and I > > am using JSTL to retrieve data and iterate with > (c:foreach). There are alot > > more fields involve here each ActionForm corrolate to a database > > tables(Atable = Aform, Btable = Bform). I would like the > user to be able > > update fields in multiple tables without binding the table > in one very big > > ActionForm. Does this fit the exception of nested forms using JSTL? > > I understand it was html-el, but that doesn't matter - you > should still > just use property when you 'can' for text fields ( if iterating over > checkboxes and displaying the values of the checkboxes with el, that > makes more sense). You shouldn't be worrying about the backend at all > from a front end perspective. The role of the front end is to capture > and display data so I wouldn't worry about: (Atable = Aform, Btable = > Bform). > > Here's what I do in your case. Imagine the slightly more > complex case of > "updating user information" Using your scenario, the set up > could be > like this: > > 1) Create an ActionForm that will be used to capture user information: > > //UserActionForm > String id > String firstName > String lastName > String homePhone > String contact1 > String contact2 > > 2) I'd use a Dispatch Action for the Action class, but since I'm not > sure if used them before, I'll assume a regular Action. So Create a > "GetUserAction" and for this example we'll also need an > "UpdateUserAction" (Dispatch really makes this much easier but that's > another topic). > > 3) User might click on a link with an userID and we then need to > populate the ActionForm so the fields (firstName, etc) can be > updated. > So imagine a link that will map to "GetUserAction" and takes request > parameter of "id." For this example we'll bind our UserActionForm for > this mapping. So we might have a link that looks like... > /getUser.do?id=3456 which in our StrutsConfig file we'd map that > getUser.do to our "GetUserAction." So GeUserAction is called... now > here's where you'll see what I'd do... > > //in execute of GetUserAction.. > > UserActionForm userForm = (UserActionForm)form; > String id = userForm.getId(); > > //now you mentioned you have different business calls to make > //to populate both contact information and the rest of the info... > //I'd think about creating a new query but lets assume you > have to make > //both calls. We'll use a service class that hides the implementation, > //but what should always be returned is some kind of BusinessObject - > //not an ActionForm... these business objects holding the data are > //ValueObjects or DTOs - just glorified names for plain old > java object > //really. > > //NameValueObject holds firstName, lastName, homePhone > NameValueObject nameObject = yourServiceLayer.getNameObject( id ); > //ContactValueObject holds contact1, contact2 > ContactValueObject contactObject = yourServiceLayer.getContactObject( > id ) > > //so now you have the concern you were talking about earlier: > //Atable = Aform, Btable = Bform - but notice now it's not based > //on the view layer. > > //now we can simply use bean utils to populate our form bean for > //the display: > > //to avoid having to do userForm.setFirstName( > // nameObject.getFirstName() ); > //for all the properties..use BeanUtils... > > BeanUtils.copyProperties( userForm, nameObject ); > BeanUtils.copyProperties( userForm, contactObject ); > > //Viola. Now your UserActionForm is nice and populated and ready to be > //used on your page. So yo forward on to your page and you have a > //nice form with... > > <html:form name="updateUser"> > first name: <html:text property="firstName"/> > //... > Contact 1: <html:text property="contact1"/> > //..etc > </html:form> > > The above of course submits to UpdateUserAction (or if > Dispatch Action > something like "UserAction" and in there you could do the reverse... > > UserActionForm userForm = (UserActionForm)form; > NameValueObject nameObject = new NameValueObject(); > BeanUtils.copyProperties( nameObject, userForm ); > ContactValueObject contactObject = new ContactValueObject(); > BeanUtils.copyProperties( contactObject , userForm ); > yourServiceLayer.updateUser( nameObject, contactObject ); > > Again I still think it makes more sense to probably have just one > ValueObject ( user ) to deal with holding all this, but you > might have > some requirement were you need to have each different object > representing a table. (Use iBATIS and you won't have to worry > about that:) > > By the way, I have some examples of this stuff at > http://www.reumann.net/do/struts/main A lot of the stuff I > do there I'd > do slightly different now but the principals are still ok. > > -- > Rick > > --------------------------------------------------------------------- > 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]
