> -----Original Message----- > From: Hollaway, Shedrick CIV (TRFKB C600) > [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 12, 2004 9:13 AM > To: 'Struts Users Mailing List' > Subject: RE: Multiple forms in one JSP + one Action > > > 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.
*LOL* I have never ever over-engineered anything any my life. *LOL* Stop giggling it's true :) I've just started looking at the struts side entirely from the users perspective, completely ignoring what my backend might look like. That allows me to design a great UI. Then, I use the action class to map the UI to my object model. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
