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]
