Hi Andi, Thank you for the explanation.
Unfortunately, I don't entirely understand it -- probably because I am not familiar with PagingScrollTable. (I am familiar with Swing's JTable/TableModel/Renderer/Editor collaboration which I believe must be remotely similar...) I was trying to grasp the underlying mechanisms through reading through the API (http://collectionofdemos.appspot.com/javadoc/com/google/gwt/gen2/table/client/PagingScrollTable.html), but I got stuck while I was trying to find out how the client code is supposed to implement the RowRenderer.renderRowValue(...) method to actually render the rows. (Or is it in a custom implementation of TableDefinition.AbstractRowView<RowType> that you actually render the rows? I could simply not crack this one....) Is it perhaps possible to describe the problem in a more abstract way? I understand that each row of the master table has about 10k slave rows associated with it. When fetching the master rows, you will fetch foreign keys for only 100 of the slave rows associated with one given master row. When the user selects a master row, you start fetching the rest of the foreign keys so that that the slave rows are loaded when the user scroll down in the slave table. Is this correct? Where does the need for synchronous calls arise? Thanks Peter On Mon, Oct 19, 2009 at 10:01 PM, AndiMullaraj <[email protected]> wrote: > > Hi Peter, > > I am trying to create a component able to display master/detail data > using PagingScrollTable. PagingScrollTable sends requests to the > server (on behalf of TableModel) specifying a starting row and a row > count (to my opinion, this is how they have gotten around the issue of > "not being able to fetch data on demand in a transparent way for the > caller"). Now, my rows can contain fields representing collection of > foreign keys (Long ids -- 8 bytes); if this collection has 10K values > that would mean 80Kb of data that won't probably be needed on the > client. Hence the idea of returning a custom implementation of a > collection instead (list/iterator/whatever) that would fetch the data > as the user consumes along. If we are able to do this in a reliable > manner, the API for fetching rows of the master table would not need > any change at all ... > > Instead (b/c I am not being able to create such a collection > accessor), I have recurred to the solution where I send 100 foreignIds > for each master field of row being requested and added getForeignIds > (...) in my DataService interface to provide access to the rest of > them) ... kind of replicating the same strategy TableModel applies > initially ... > > public interface DataService<RowType> extends Service { > List<Long> getForeignIds(Long rowId, String fieldName, int startRow, > int numRows); > > List<RowType> getRowsByIds(List<Long> ids); > > int getRowCount(); > > RowType insertRow(); > > void removeRow(RowType rowValue) throws VersioningException; > > List<RowType> requestRow(int startRow, int numRows); > > void updateRow(RowType rowValue) throws VersioningException; > } > > Hope this makes a good case for sync calls (I have experience in > client/server protocols but am novice in the browser world and don't > know how to do this), I am a stron believer of the assync APIs but > there are cases (like this one) that make indispensible the sync APIs. > > Thanks averybody else for the answers offered in this thread -- I will > check them out ASAP. > > Andi Mullaraj > > > On Oct 17, 4:40 pm, Péter Kovács <[email protected]> wrote: > > I'd still be interested in the use case which makes the ability to make > > synchronous calls so desirable/indispensable -- at the GUI level. Would it > > be possible to share this use case with us (or personally with me, if you > > prefer). > > > > Thanks > > Peter > > > > On Sat, Oct 17, 2009 at 1:13 AM, AndiMullaraj <[email protected]>wrote: > > > > > > > > > > > > > Thank you both for your prompt and attentive replies. I was fearing > > > the answer I got from Shawn as it looks it won't be possible to > > > partially fetch a long collection from the server (and then fetch > > > items on demand). The classic collection/list interfaces don't have > > > the notion of "not available yet" embedded in their method definitions > > > so even if you cache a big nr of items coming from the server > > > initially, there is no guarantee the client won't consume those faster > > > than the connection can handle ... which obsoletes the solution > > > proposed by Lazo (I had the same idea initially). > > > > > So, all classic collections (and other classic alikes) would have to > > > be be fetched totally before their construction ... argh! ... Or maybe > > > my reasoning is wrong? > > > > > Thanks again, > > > Andi Mullaraj > > > > > On Oct 16, 12:59 pm, Lazo Apostolovski <[email protected]> wrote: > > > > Just a little change. You need to remove command from list before call > > > > execute(); > > > > > > On Oct 16, 1:48 am, AndiMullaraj <[email protected]> wrote: > > > > > > > There are cases when blocking calls to server are indispensable > > > > > (agreed, assync calls are the way to go for 99% of the cases). > > > > > > > I scanned the client API and cannot find a way on how to do this. If > > > > > not through a direct API call, is there a way on how to achieve this? > > > > > (Like having a wait/process_events loop going until the response comes > > > > > from the server). > > > > > > > Thanks for you attention, > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
