[Javascript] Timing Issues

Mike Dougherty mdougherty at pbp.com
Mon Jul 21 09:47:38 CDT 2003


Are you issueing the data request from the client?  If yes, you could
request data in smaller chunks, and write the data in whatever chunk
size you want.  Probably no, because that approach opens other security
related issues (and would lead to allowing cross-domain
scripting/requests)

I don't know about PHP, but the ASP model uses buffering to cache the
whole HTML page before submitting it to the browser - but you can also
flush the buffer periodically during the page composition steps - which
would give the look and feel of an updating page (as long as the results
can adequately be expressed in a stepwise manner)

Another idea would be to cache the resultset of your query on the
server, then show smaller pages - of course, that would require a paging
scheme which can become complicated or cumbersome.  The benefit of
server side caching is that you might never have to send all the data
across the internet to the client, which could be a significant
load-time performance increase.  The downside is that there could be a
large number of round-trips from the user to the server requesting
pages, as well as the complexity involved with implementing the cache
and paging routines.

If the purpose is more of an analytic nature, it might be better to
suffer the long download of data then manipulate a local cache in some
format (like XML)  

Usually the answer to this type of problem revolves around your answer
to the question, "Why does the client really need such a humongous
recordset?  If we provide a decent filter mechanism, would it be
possible to have the user request less data in the first place?"  In the
cases I've seen, the marketing department (for example) requests 2
million records because they 'want everything' so they can pick out the
10-20k records of interest.  There's no way they can eyeball that much
data, so they are filtering what IT delivers anyway...

Or did I miss the point altogether?

-----Original Message-----
From: javascript-bounces at LaTech.edu
[mailto:javascript-bounces at LaTech.edu] On Behalf Of David Lovering
Sent: Monday, July 21, 2003 9:22 AM
To: [JavaScript List]
Subject: [Javascript] Timing Issues


*This message was transferred with a trial version of CommuniGate(tm)
Pro*
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




More information about the Javascript mailing list