On Wed, Mar 4, 2009 at 2:53 PM, Jesse Callaway <bonsa...@gmail.com> wrote:
> On Wed, Mar 4, 2009 at 1:07 PM, David Mintz <vtbludg...@gmail.com> wrote: > > > > On Wed, Mar 4, 2009 at 12:17 PM, John Campbell <jcampbe...@gmail.com> > wrote: > >> > >> >> Use AJAX instead to refresh just the part of the page that needs > >> >> refreshing. If it's a fair chunk of information, you set a "version" > >> >> on the server so the AJAX call just checks the current version vs > it's > >> >> version. If it's different, then you refresh the content. If it's not > >> >> different, no need to refresh anything and you only did a light > weight > >> >> server call, so you could do it every 15 seconds. > >> > > >> > Forgive me, I don't quite understand *how* you would set the version > >> > information on the server in order to compare. > >> > >> In many cases, you can get away with using timestamps. If you have > >> update_at columns, then you can compare the timestamps. In theory, > >> there are problems with this method (such as updates that happen > >> during the same second), but in practice, it works quite well. > > > > > > Still not sure I get it -- I am competing the for Slowest Mind of the > Year > > Award. > > > > The users are looking at a set of database rows. The table does have > > last-modified and creation-datetime columns. Saving the current set's > > maximum last-update and/or created value in the client, and then checking > > against the server by running an Ajax request to a server-side script > that > > in turn queries the db to see if anything has changed... seems like > almost > > as much overhead as just reloading unconditionally. Indeed more in those > > instances where you query to check if something changed, then do another > > query to load the data because something did change. > > > > And by "change" I mean in the dataset they are looking at, a row may have > > been either created, updated or deleted since they last loaded the view. > So > > last-modified values would not inform you about deletions. > > > > I don't understand the md5() technique either. I mean, I know about md5() > > but don't see how you would use it efficiently for this purpose. > > > > -- > > David Mintz > > http://davidmintz.org/ > > > > The subtle source is clear and bright > > The tributary streams flow through the darkness > > > > _______________________________________________ > > New York PHP User Group Community Talk Mailing List > > http://lists.nyphp.org/mailman/listinfo/talk > > > > http://www.nyphp.org/show_participation.php > > > > Get a hash of the data returned from your remote request and remember > it at the client. If you choose you can remember it on the server-side > as well. But you might not have control over that, say if you are > grabbing the weather from a provider. > Anyway next time you get a response back check it against the > remembered md5. If there's a match then don't update the document. I > don't know if it's efficient or not, but it would cut down on > redrawing the screen. > Understood. Thanks! -- David Mintz http://davidmintz.org/ The subtle source is clear and bright The tributary streams flow through the darkness
_______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show_participation.php
