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]> > > > > > > > . > > > > > > 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.
