Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for mconfusion)

[Eddie Bush]

(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.

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>