Pass to the helper class the PrintWriter, have it do the printing.
Also, have it decide what to show and what not to show. In that way, the helper
class is responsible for user interface. There is no reason for the servlet to
have to pass back to the user the html -- have the helper class do it.
"Mukhar, Kevin" wrote:
> Well, in the interest of brevity, I left some information out of my original
> response. The servlet does not do any looping or concatting of strings. That
> is all done by another class.
>
> First, we didn't want the servlet messing with the database. The servlet
> gets a request and passes it to a class which encapsulates the kind of data
> the query is for. The servlet handles http requests and http responses. The
> QueryData class handles queries, updates, deletes, etc. Different data
> classes for different kinds of data (i.e., if this were Amazon.com we might
> have a data class for books, one for music, etc., because those things are
> in different tables in the DB)
>
> Second, we didn't want to hard code the user interface into the servlet,
> because then foreign customers can't customize the user interface into the
> local language. So the HTML pages are templates. The QueryData class inserts
> the results into the template, then the class gives the filled in template
> as a string to the servlet to pass it back to the user.
>
> Third, we don't display all columns from the DB to the user. The first
> display is just some of the columns, and then the user can select a
> particular result to view all the data for that result. In an example of
> data hiding, we didn't want the servlet to worry about what is shown to the
> user and what isn't. The servlet asks the QueryData class for the string to
> send back to the user, the QueryData class determines what is to be shown.
>
> So that's why there's a class in our system that takes the query results
> from a DB query, sticks HTML tags around the appropriate data, and stuffs it
> all into a string which can be given to the servlet to send to the browser.
>
> Kevin Mukhar
>
> > ----------
> > From: Scott Neufeld[SMTP:[EMAIL PROTECTED]]
> > Reply To: [EMAIL PROTECTED]
> > Sent: Thursday, May 20, 1999 1:02 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Displaying more than 250 rows....
> >
> > Just output the html as you loop through the resultset, you won't get into
> > any
> > memory problems (on the java servlet side) at all. Why bother
> > concatenating
> > strings or creating StringBuffers?
> >
> > You may run into a problem displaying an HTML table with >1000 rows,
> > because of
> > memory constraints on the client side associated with very large tables.
> > You can
> > get around this by fixed-length columns and displaying with <PRE> .
> >
> >
> > "Mukhar, Kevin" wrote:
> >
> > > Yes, We have been able to do it on the project I work. We are using
> > > Oracle 8
> > > JRUN 2.3
> > > JSDK 2.1
> > > Solaris 2.6
> > > oracle.jdbc.driver.OracleDriver
> > >
> > > In the first iteration of the project, displaying query results did not
> > use
> > > any "paging" concept. If the user made a query that returned 1000 rows,
> > > that's what was displayed.
> > >
> > > Like you, we had a problem when retrieving and displaying a large amount
> > of
> > > data. The problem for our project was in the way we were building the
> > > display for the user. We created part of the HTML page by doing a bunch
> > of
> > > string concatenations:
> > > String s;
> > > while (notDone) {
> > > s = s + nextRow;
> > > }
> > > And then when the entire page was built, writing to the output stream.
> > Our
> > > problem was an out of memory error while doing the string
> > concatenations.
> > >
> > > To fix the problem, we changed the code to use StringBuffers which were
> > > pre-allocated to the proper size, and limiting the amount of rows to
> > 650.
> > > It's hard to say, but that could be one of the problems inside your
> > while
> > > loop.
> >
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
