See intermixed. On Tue, 12 Nov 2002, Martin Cooper wrote:
> Date: Tue, 12 Nov 2002 08:36:13 -0800 > From: Martin Cooper <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> > Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() > for m confusion) > > > > > -----Original Message----- > > From: Sri Sankaran [mailto:Sri.Sankaran@;sas.com] > > Sent: Tuesday, November 12, 2002 7:56 AM > > To: Struts Users Mailing List > > Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() > > for m confusion) > > > > > > No sweat. > > > > The reason this discussion got so off whack was because I > > tried to slam a square peg in a round hole by continuing with > > Kris' example (Edit & Save actions) to make my point -- bad idea. > > > > So what *is* my scenario? > > > > Consider for example, a master-detail pair of pages. The > > master page display a list of employee names. The detail > > page -- which is displayed when a user selects an employee > > from the master page -- displays a collection of (possibly > > editable) fields that describe the selected employee. > > > > The form-bean associated with the detail page is your typical > > EmployeeBean object. Even if the struts-config is set up > > with the right action mapping like > > > > <action path="/detail" > > type="com.acme.DetailAction" > > name="employeeBean"/> > > > > how can Struts know that the user selected the user 'John > > Smith' on the master page? Ergo, the need to create the > > necessary form bean in the action for the master page. We > > cannot wait for/depend on Struts to create it. > > > > I don't like the fact that the MasterAction needs to have > > knowledge of the requirements for the detail page (the type > > of bean, the name under which it is accessed) -- or maybe > > that isn't so bad....?? > > Yes, it is bad. Actually, it's a bit of a mystery to me that this issue > doesn't come up more often (or perhaps I just always miss it). > > One solution (which Craig would probably shoot me for mentioning :) Yep :-). For those who tuned in late, I am *not* a fan of this -- in part because it has some pretty unexpected semantics w.r.t. form beans. > is > action chaining. That is, your master action chains (i.e. forwards) to a > detail action that prepares the bean for the detail page. There are some > problems with chaining actions, though, so it's not the best way to handle > this. > > An alternative is to split your actions into two phases, and keep the logic > of those two phases separate, using additional classes. This is what I'm > doing now, and it's pretty clean. Unfortunately, at this point my employer > owns the code, but I'll see if I can wrest it free at some point. ;-) If you know what your destination action's path is, you actually *can* divine what form bean is needed pretty easily. Let's assume we're talking about the ultimate action at path "/foo": ApplicationConfig appConfig = (ApplicationConfig) request.getAttribute(Globals.APPLICATION_KEY); ActionConfig actionConfig = appConfig.findActionConfig("/foo"); String name = actionConfig.getName(); // Form bean name String attribute = actionConfig.getAttribute(); // Attribute to store under String scope = actionConfig.getScope(); // Scope to store in FormBeanConfig fbConfig = appConfig.findFormBeanConfig(name); Now you've got all the metadata you need to dynamically instantiate the appropriate form bean, and store it under the appropriate attribute in the appropriate scope, without hard coding any of this stuff. > > -- > Martin Cooper Craig -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
