[Javascript] Timing Issues

[David Lovering]

Dear Chris:

All good ideas.  Unfortunately, in the former iteration I did have paging --
and got complaints from folks who wanted to print entire tables for reports
without segmentation issues getting in the way of the layout.  Business
majors -- go figure.

Although I'm certain the 'table per row' solution would work, the overhead
would be extremely gruesome, and I'll hold that trick in reserve until I've
exhausted everything else in the bag.

Have you any experience with createElement to "grow" an already displayed
table?  How does this affect the background latency to load the whole table?

The 'response.flush' feature might indeed work, particularly if I can force
the event handler to act on it after the "build" of each record.
Of course, since the screen geometry is set by "worst-case" TD
widths/heights, the whole screen will jitter like a hornytoad on a hotplate
as differing field lengths come pouring in.  Hmmm... some testing is in
order.

-- Dave Lovering
----- Original Message -----
From: "Chris Tifer" <christ at saeweb.com>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Monday, July 21, 2003 8:05 AM
Subject: Re: [Javascript] Timing Issues


> First, the obvious thing would be to page your results so that there's not
> so much info in one shot unless it's absolutely neccessary (in most cases,
> it
> is NOT neccessary to give them all the info on one page).
>
> If that's not an option, a table won't render until it's complete, so your
> best best
> (although it will tremendously increase HTML file size) would be to put
each
> individual record in it's own table so that way by the time the next
record
> was being written out, the previous table would be complete.
>
> Now I don't know about PHP, but in ASP, you can set buffering on code
> and if you have that turned on, nothing will be sent to the client until
the
> entire
> bit has been run.
>
> To send the processed HTML to the client, I would use:
>
> response.flush
>
> Hope that might help a little.
>
> Chris Tifer
> http://emailajoke.com
>
> ----- Original Message -----
> From: "David Lovering" <dlovering at gazos.com>
> To: "[JavaScript List]" <javascript at LaTech.edu>
> Sent: Monday, July 21, 2003 10:22 AM
> Subject: [Javascript] Timing Issues
>
>
> > One of the apps I'm working on now is a database engine for a web-site
> which
> > occassionally requires humongous tables to appear on the remote
> > (client-side) screen.  Since I'm using a combination of server-side
> PHP/SQL
> > and client-side JavaScript to paint this, there are timing issues
involved
> > on both sides.
> >
> > Aside from indexing, caching, hash-codes, compression, etc. (which I'm
> > investigating), one obvious way to appease the user on the client window
> is
> > to paint the screen record-by-record as the data comes in, rather than
> > waiting until the entire table is completed before updating the
aforesaid
> > window.  What is the best way to do this?  Are there any JavaScript/DOM
> > directives that will force intermediate updates rather than waiting for
> the
> > object load to complete?  Should I use the createElement directive to
> build
> > each <tr> as a separate object?  Does anybody have any feel for this?
> >
> > -- Dave Lovering
> >
> >
> > _______________________________________________
> > Javascript mailing list
> > Javascript at LaTech.edu
> > https://lists.LaTech.edu/mailman/listinfo/javascript
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>
>