Reasonable? Absolutely! Workable? Can you extend AsyncDataProvider to add the desired buffered behavior? That would be the first place I'd look if I needed a buffered asynchronous data provider. With a little generality thrown in, you'd be able to reuse the component for all async requests that would benefit from buffering.
Jeff On Mon, Dec 13, 2010 at 1:46 PM, Greg Dougherty <[email protected]>wrote: > Hi Jeff, > > While I'd definitely be sorting the data on the server side, what I > was thinking of doing was downloading records in the background, so > that they'd already be on the client by the time the user clicked to > go to the next page (and saving records that have already been > downloaded, so if the user goes forward and backwards things are only > downloaded once). The concerns being: > > 1: Not wanting to overload the server with data requests that the user > will never actually look at. > 2: Not wanting to overload the client storing vast amounts of data > that the user will never actually look at. > > I'm thinking perhaps grabbing the next two "pages" of data (when one > download ends, check to see where the user is, and what's been > downloaded, and if the next two pages (from the user's perspective) > aren't already down, request the next one that isn't local. (I.E. if > page 2 comes back, and the user is on page 1, then save the results, > and fire off a request for page 3.) > > Reasonable? Workable? > > Thanks, > > Greg > > On Dec 13, 11:10 am, Jeff Schwartz <[email protected]> wrote: > > On Mon, Dec 13, 2010 at 11:08 AM, Greg Dougherty < > [email protected] > > > > > > > > > wrote: > > > Hi Jeff, > > > > > As I'm dealing with unpublished research data, Google App Engine is > > > not an option. That said, I'm all in favor of offloading as much work > > > to the client as possible. :-) > > > > > I'm doing all my filtering on the server. We're defining the filters > > > the users can use (not my choice, oh, well), so I have a shared class > > > where the client side tells it what filters to use, then passes it to > > > the server, where the class creates the SQL SELECT commands the server > > > side classes use. The server keeps the result set of the search open, > > > and retrieves records as the client requests them. > > > > > So far, even a tightly filtered search gets 4000+ results, so I'm not > > > going to make the user wait to download all the data before seeing any > > > of it. OTOH, I suppose I could have a background thread downloading > > > records while the user is looking at the current ones. > > > > That depends on, of course, if that fits your use-case. With such a large > > result set I'd provide the option to sort to the user but I would do the > > actual sorting on the server using the data store's sorting capabilities > . I > > know this contradicts what I said before but the line has to be drawn > > somewhere and I'd draw the line as far as client vs. server sorting at a > few > > hundred records max for client side sorting; over that I'd opt to do it > on > > the server. > > > > > > > > > Is there any way to tell how much memory is available for my app, so > > > that I can spend a reasonable amount of it holding data from the > > > server? > > > > I assume you are asking about the size of client-side memory available to > > the javascript run time, correct? If so then I believe that for arrays > the > > max number of elements is 2^32 - 1 or 4294967295 and the max length for > any > > item also cannot be greater than that. These numbers are provided along > with > > a caveat -- I don't believe these numbers are always or even ever > obtainable > > due to the variations of the amount of client memory, browsers, the max > > amount of actual memory made available to the browser, etc. > > > > Jeff > > > > > > > > > Thanks, > > > > > Greg > > > > > On Dec 10, 12:26 pm, Jeff Schwartz <[email protected]> wrote: > > > > You are absolutely right about the async data provider. With large > data > > > sets > > > > then this is absolutely the way to go. I thought though that you were > > > > talking about how to sort the data once it was being viewed in the > client > > > > which you still might want to do even if you are using the async > data > > > > provider. > > > > > > For instance, if you provide the user with the ability to view > subsets of > > > > data based on a filter and you bring down all the data matching the > > > filter > > > > you still might need or want to provide the user with ability to sort > the > > > > data on the client as opposed to having to call back to the server > again. > > > > > > This is especially convenient to use if you are targeting App > Engine's > > > > Datastore because the less you do on App Engine's servers (the faster > > > your > > > > request is) the better it is due to App Engine response time quotas. > I am > > > > currently crafting an application for App Engine with GWT and I am > using > > > > this technique a lot. I use an initial ordering when I query the > > > Datastore, > > > > bring down the data and if the user alters the data or adds to it I > sort > > > it > > > > locally in the client. Though I haven't implemented it yet, I will > also > > > use > > > > this same technique to allow the user to do cell table sorting with > the > > > > data. > > > > > > My mantra for dealing with the tight quota limits imposed by App > Engine > > > is > > > > lean and mean on the server and thick client where I have all the > > > breathing > > > > room I need to perform data manipulation. > > > > > > Jeff > > > > > > On Fri, Dec 10, 2010 at 12:20 PM, Greg Dougherty < > > > [email protected] > > > > > > > wrote: > > > > > Hi Jeff, > > > > > > > Thanks. Of course I'm need this for an AsyncDataProvider (the > data's > > > > > on the server, not the client. At 78,000+ rows I'm only bring over > > > > > the ones I need). So my comparator classes provide SQL command > > > > > strings to the server to sort the data. > > > > > > > I must admit, I am curious: Do people actually use a CellTable to > > > > > display local data? I thought the whole point of them was to let > you > > > > > download subsets of your data from the server. No? (Note: this > isn't > > > > > a "why aren't you making code that I can use" whine, since even if > you > > > > > did an AsyncDataProvider example, it would be using an ORM, and I > > > > > don't use those). > > > > > > > Greg > > > > > > > On Dec 10, 9:48 am, Jeff Schwartz <[email protected]> wrote: > > > > > > When the user clicks on a column header you would get the list of > > > data > > > > > via > > > > > > the ListDataProvider associated with the table and sort the list > as > > > per > > > > > the > > > > > > needs of your application. You can maintain state for the current > > > > > ordering > > > > > > and a second click on the column header can reverse the ordering > of > > > the > > > > > > sort. Once the sort is done you then just refresh the > DataProvider > > > and > > > > > the > > > > > > table will refresh to reflect the changes to the list. It is > quite > > > > > simple. > > > > > > > > Jeff > > > > > > > > On Thu, Dec 9, 2010 at 11:17 AM, Greg Dougherty > > > > > > <[email protected]>wrote: > > > > > > > > > My users would like to be able to sort my CellTable by clicking > on > > > a > > > > > > > Column title. Is there an existing GWT widget for putting a > > > downward > > > > > > > or upward pointing triangle in a CellTable Column title? For > that > > > > > > > matter, what do I have to do to get a mouse click IN a Column > > > title? > > > > > > > > > Thanks, > > > > > > > Greg > > > > > > > > > -- > > > > > > > You received this message because you are subscribed to the > Google > > > > > Groups > > > > > > > "Google Web Toolkit" group. > > > > > > > To post to this group, send email to > > > > > [email protected]. > > > > > > > To unsubscribe from this group, send email to > > > > > > > [email protected]<google-web-toolkit%[email protected]> > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > > > > > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > > > > > > > > > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > > > > > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > > > > > > > > > > > . > > > > > > > For more options, visit this group at > > > > > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > > > > > > -- > > > > > > *Jeff Schwartz* > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > "Google Web Toolkit" group. > > > > > To post to this group, send email to > > > [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<google-web-toolkit%[email protected]> > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > > > > > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > > > > > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > > > > -- > > > > *Jeff Schwartz* > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Google Web Toolkit" group. > > > To post to this group, send email to > [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<google-web-toolkit%[email protected]> > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > > -- > > *Jeff Schwartz* > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- *Jeff Schwartz* -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
