Comments in here somewhere... > -----Original Message----- > From: Eddie Bush [mailto:ekbush@;swbell.net] > Sent: Tuesday, November 12, 2002 12:22 PM > To: Struts Users Mailing List > Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() > for m confusion) > > > (waaaaaaaaaaay down there ...) > > Sri Sankaran wrote: > > >Intermixed response... > > > >>-----Original Message----- > >>From: Eddie Bush [mailto:ekbush@;swbell.net] > >>Subject: Re: [SIDEBAR] Form population (Was RE: > >>request.setAttribute() for m confusion) > >> > >>Sri Sankaran wrote: > >> > >>>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. > >>> > >>> > >>> > >>John Smith has some unique identifying value, right? > You're going to > >>need to grab this value on submit and send it to your detail > >>action so > >>that it knows which one to load. > >> > >> > >But when the master page is submitted, it is *MasterAction* > that is being invoked and not DetailAction. DetailAction > doesn't come into the picture until the detail page is submitted. > > > Yes, it is. That is why you retrieve whichever pertient > value it is the > detail will need and then send control to the detail action - > and let it > load the data relevant for the view and forward to it. If > you're asking > for a detail view for one row in the master, then you obviously have > some unique value (or group of values - a key) by which you determine > the relationship. This is the information you must somehow make > available to the detail view - as request parameters or in some other > way. Personally, I tend toward using OIDs, so ... since > you're probably > going to have the OID of the master as a field of the detail you can > send that OID to the detail as some parameter - call it recordId or > whatever you like.
Aaaaahhh! The murky waters finally clear, and I understand where all the confusion is coming from. Sri and I are talking about one Action handling the request. You (Eddie) are talking about two Actions chained together. Better not let Craig catch you, Eddie! ;-) -- Martin Cooper > > The information you use to load the detail doesn't differ > with respect > to where you retrieve it. That data will be just as happy it was > retrieved from the master action as it will be if it is > retrieved from > the detail action. By placing the responsibility for that > behavior upon > the detail action you rid the master of caring about it - and > you remove > the need for your master to create the form for the detail. > > LoadAction -> Form (JSP) -> SubmitAction > > action loads data into form and forwards to view > view is sent to action to determine next step > > ... you've got two of these back-to-back: > > MstrLdActn -> MstrJsp -> MstrSbmtActn - - > DtlLdActn -> DtlJsp -> > DtlSbmtActn > a redirect passing mastid=54 ^^^^^ > > <snip/> > > -- > Eddie Bush > > > > > -- > To unsubscribe, e-mail: > <mailto:struts-user-unsubscribe@;jakarta.apache.org> > 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>
