David,
You can make sure data is available from servlet call to servlet call in
various ways. One way would be to save data in hidden inout fields with
your form data. Another way is to ensure that that data has been saved with
a session object and can be referenced as necessary.
Personally what I'd do in a employee/employee detail scenario is gather the
data needed to provide the employee listing, and then gather the employee
data only as requested. So your detailedResult servlet will be given the
employee id, do the database call and return the employee details. Any
other information you need that you don't return from that database call
could be stored for reuse with the session.
Dan
--
Daniel Kirkdorffer
Sr. Consultant, Syllogistics LLC
Web: http://www.syllogistics.com/
Email: [EMAIL PROTECTED]
> ----------
> From: David Mossakowski[SMTP:[EMAIL PROTECTED]]
> Reply To: David Mossakowski
> Sent: Wednesday, April 14, 1999 9:32 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementing Model 2 - Searching a database
>
> I have a very important question to ask.
>
> When the searchResults are displayed and links are provided to
> view detailed information on an employee, then clicking
> on that will give another servlet (detailedResult) the id,
> but how about other information? Such as other variables that were
> saved in that user's session? Do they implicitly get passed too?
>
> Moreover, how to LOOP the results and have a link to detailServlet
> with one parameter as the ID?
>
> Is this possible?:
> <LOOP property="searchResults:employee" propertyelement="i">
> <a href=/detailServlet?<display property="i:ID">>
> <display property="i:firstName">
> </a>
> </LOOP>
>
> Then if the above syntax is correct (which it probably is not) does the
> session information still get passed to the detailServlet?
>
> What am I missing here?
>
> dave.
>
>
> D J wrote:
>
> > Imagine a simple Model 2 web-app that allows user to search an
> > employee database. There are 3 steps in this process (excluding
> > error handling).
> >
> > 1) User enters name to search for (ie. "Smith")
> > 2) All the matching employees are displayed in a list of names (first
> > and last name). The user click on one of the names (or a button
> > beside the name)
> > 3) The entire employee information now would appear.
> >
> > I think I under how to implement the processing between step 2 and
> > step 3. Clicking on one of the names could send the request to a
> > servlet. Parameters like an employee number could be part of the URL
> > request. The servlet would use the request parameters to query the
> > end database. The results from database would be placed into an
> > Employee bean that is sent to a JSP page for display (step 3).
> >
> > But how do you use beans to perform step #2? Are the results of the
> > database query stored into a kinda of "EmployeeSearchResults" bean
> > that would allow multiple values? Or could an enumeration of
> > Employee beans be used?
> >
>
> My approach to this would be something like this: define an
> EmployeeSearchResults bean that has a multivalued property named
> "employee"
> that returns an Employee bean (you can re-use the one you created for step
> 3).
> In other words, your bean would have a method like this:
>
> Employee getEmployee(int index);
>
> I am assuming that you've defined the Employee bean to have (among others)
> first name and last name properties:
>
> String getFirstName();
> String getLastName();
>
> Now, you can use all of this to construct an HTML table containing the
> results,
> by using the <LOOP> tag in your JSP page:
>
> <usebean name="searchResults" type="...">
> </usebean>
>
> <table>
> <tr>
> <th>First Name</th>
> <th>LastName</th>
> </tr>
> <loop property="searchResults:employee" propertyelement="i">
> <tr>
> <td><display property="i:firstName"></td>
> <td><display property="i:lastName"></td>
> </tr>
> </loop>
> </table>
>
> I use "i" to be reminiscent of the usual loop control variable naming
> convention. Loops can also be nested, and I would use "j" for the next
> level,
> and so on.
>
> Note that you don't have to declare anything about the Employee bean at
> all,
> because the JSP page introspects as necessary to get its properties.
> That's
> pretty slick in my book.
>
> Craig McClanahan
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff JSP-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
