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
-~----------~----~----~----~------~----~------~--~---
