Intermixed response... > -----Original Message----- > From: Craig R. McClanahan [mailto:craigmcc@;apache.org] > Sent: Tuesday, November 12, 2002 1:54 PM > To: Struts Users Mailing List > Subject: RE: [SIDEBAR] Form population (Was RE: > request.setAttribute() for m confusion) > > > 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.
This goes from having to have information about the bean to having information about the action path. Six one way, half dozen the other? > > > > > -- > > Martin Cooper > > Craig > Sri > > -- > To unsubscribe, e-mail: > <mailto:struts-user-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:struts-user-help@;jakarta.apache.org> > > -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
