Re: Local data cache when using AsyncDataProvider (CellTable)
Hello, 1)Your use of AsyncDataProvider seems interesting to me but I have a few questions. My Celltable also use sorting. But then when you change sorting order the same method (onRangeChange) is called as when you change page. Problem is that the behavior must be different: when I change page I'd should check if the data is availlable in the local client cache, but when sorting change I have to send a new request to the server as sorting is managed server side. How do you differentiate those 2 cases? Is there a good way to do it? Should I customize the pager? Thanks for your help Ben On Saturday, January 28, 2012 6:46:14 PM UTC+1, Ümit Seren wrote: > > Well I have an application in which I display 1.2 million items in a > CellTable (50 items at a time). > I solved that by using AsyncDataProvider and doing bulk-requests of around > 2000 items (you can play with that vaue). > > I have a SimplePager which displays 50 of them at a time and when the user > pages through it it won't do any server request until the list of 2000 is > completed. Then I request the next 2000 items (actually that is > automatically taken care of by the AsyncDataProvider interface). > > For filtering/searching I implemented a hybrid approach. For example if > the user types in a string for a name it will first search on the server. > Again only 2000 items will be sent back from the backend. For each new > character I will do another server-request. However I also return the > number of hits (which the search returns). If the number of hits is smaller > than 2000 the next time the user types in another character it will only > search on the client side (because I already have the whole search set > transfered to the client). > > For sorting you can take the same path. > > To be honest I am not sure if it's worth just sending the IDs and then > replacing it later with a second call with the missing real objects. I > don't think it will be much of a performance problem even when you have a > lot of user requests at the same time. You can try to solve that problem on > the backend (via caching, etc) and if you still have an issue you can > implement your approach. > Don't forget Knuth famous quote: "*Premature optimization is the root of > all evil"* > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/mEFB8TQLB50J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Local data cache when using AsyncDataProvider (CellTable)
Well I have an application in which I display 1.2 million items in a CellTable (50 items at a time). I solved that by using AsyncDataProvider and doing bulk-requests of around 2000 items (you can play with that vaue). I have a SimplePager which displays 50 of them at a time and when the user pages through it it won't do any server request until the list of 2000 is completed. Then I request the next 2000 items (actually that is automatically taken care of by the AsyncDataProvider interface). For filtering/searching I implemented a hybrid approach. For example if the user types in a string for a name it will first search on the server. Again only 2000 items will be sent back from the backend. For each new character I will do another server-request. However I also return the number of hits (which the search returns). If the number of hits is smaller than 2000 the next time the user types in another character it will only search on the client side (because I already have the whole search set transfered to the client). For sorting you can take the same path. To be honest I am not sure if it's worth just sending the IDs and then replacing it later with a second call with the missing real objects. I don't think it will be much of a performance problem even when you have a lot of user requests at the same time. You can try to solve that problem on the backend (via caching, etc) and if you still have an issue you can implement your approach. Don't forget Knuth famous quote: "*Premature optimization is the root of all evil"* -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/IeGIOrFVgyIJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Local data cache when using AsyncDataProvider (CellTable)
Hello everyone! I have a problem understanding something.. or rather: figuring out a good way to do what I want to. On my backend I keep a list of Item-objects (which are loaded when the backend application is started on the servlet container). There are about 2 objects and each of them can have up to 100 attributes. My aim is to transfer them as seldom as possible - in fact I want to transfer them just once. The problem is the sorting: in order to sort and filter the objects to the users liking, I have to ensure that my server sorts all the Item-objects. What I have now: - CellTable of Item-objects (containing the attributes that I want to turn into columns) - AsyncDataProvider, that runs a RPC-request once the user alters the view (page-, sorting- or filtering-change) What I want to do/have: - the same CellTable of Item-objects - run a RPC-request for sorting/displaying data, BUT including an ID- list of items (just their IDs) that are already available on the client in order for the method not to include them, but just their IDs in the response - have the reply checked for the Item-dummy-objects, that contain just the ID (and are already loaded on the client), and replace them with the loaded Item-objects I'd manually implement all that, but maybe there's is a better way of accomplishing this? Maybe someone with more experience than me has a better idea? It's not that the objects are too big. It's just that there might be lots of request coming from several (even several hundred) users at once and that's why I want my application to save bandwidth wherever possible by loading static data just once (especially if it's very unlikely for it to change) and if it needs to be sorted, use IDs or something to not resend the data, because the items themselves won't have changed; just their order would. Thanks for reading and any help in that regard is greatly appreciated! Igor. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
