You need to break it up into separate tables, in chunks, if you want portions to
display incrementally, rather than the whole table all at once. The reason the
browser waits is beacause if it started rendering the table, but some row down
in the ~1000 area had an especially wide <td> cell, then it would have to push
all it's neighbors over and re-render the table. So, browsers wait until they
see a closing </table> tag. It doesn't have much to do with any server-side
technology.

If you just *have* to show something to the user while they wait for the whole
table, you could try making a separate, complete "header" table. The browser
would display it first, then chug away building the table for the hundreds of
rows.

Good luck,
NAT

> -----Original Message-----
> From: Davide Bruzzone [mailto:Davide.Bruzzone@;ngt.com]
> Sent: Friday, November 01, 2002 1:03 PM
> To: 'Struts Users Mailing List'
> Subject: RE: WebLogic/Struts/JSP performance woes...
>
>
> Yes...
>
> Again, what's strange is that during my extensive tests/experiments/hair
> pulling sessions I've actually seen this type of code work (using tables) -
> There's still a small lag between when the page clears and when the output
> starts to appear, but output definately starts to appear before the server
> is done:
>
> for (int i = 0; i < myCollection.size(); i++) {
>       out.print("</tr>");
>       out.print("<td>");
>       out.print(myData);
>       out.print("</td>");
>       out.print("</tr>");
>
>       out.flush();
> }
>
> Although by that point, the page that I was using to perform the tests had
> been tinkered with extensively, so not all the table tags may have been
> there which might have allowed the browser to render the output sooner. What
> other tags would you suggest? divs?
>
> Cheers...
>
> Dave
>
> -----Original Message-----
> From: James Mitchell [mailto:jmitchtx@;telocity.com]
> Sent: Friday, November 01, 2002 1:55 PM
> To: Struts Users Mailing List
> Subject: RE: WebLogic/Struts/JSP performance woes...
>
>
> Also, are you using tables to display?
>
>
> You know....
>
> <table>
>  <tr>
>   <td>inserting data here......
>
>
> Are you aware that these tables won't be displayed until all text required
> for this table have been downloaded?  (This is true for IE and most others
> I'm sure)
>
>
> James Mitchell
> Software Engineer/Struts Evangelist
> http://www.open-tools.org
>
> "Only two things are infinite, the universe and human stupidity, and I'm not
> sure about the former."
> - Albert Einstein (1879-1955)
>
>
> > -----Original Message-----
> > From: Karr, David [mailto:david.karr@;attws.com]
> > Sent: Friday, November 01, 2002 3:49 PM
> > To: Struts Users Mailing List
> > Subject: RE: WebLogic/Struts/JSP performance woes...
> >
> >
> > Is your page precompiled?  Are you doing the timing test on your
> > second display of the page?  The first display of a
> > non-precompiled JSP will take much longer, as it has to generate
> > and compile the servlet class.
> >
> > > -----Original Message-----
> > > From: Davide Bruzzone [mailto:Davide.Bruzzone@;ngt.com]
> > > Sent: Friday, November 01, 2002 12:43 PM
> > >
> > > I have a page that, for test purposes, is generating a 1760
> > > row table (Not a
> > > gigantic table by any stretch of the imagination). Although I
> > > don't expect
> > > our data sets to be this big all the time, I need to make the
> > > application
> > > responsive (i.e. If it starts displaying rows immediately -
> > > while its still
> > > spitting out other rows - that's fine. What's unacceptable is if the
> > > application takes a while to do whatever its doing, and
> > > doesn't generate any
> > > output until its done, leaving the user with a blank page
> > > while they wait).
> >
> > --
> > 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>
>
> --
> 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>

Reply via email to