Request Factory question

[kospiotr]

How do you deal with pagination and Request Factory? The object you have to obtain from request should be:

PagingLoadResult<ModelData>

but even with polymorphyzm from 2.4 version of GWT I'm not able to transport such generic object through RF. Have you got any idea how to resolve this?

[Colin Alworth]

@ProxyFor(BasePagingLoadResult.class)
public interface MyRfPagingResultsProxy extends PagingLoadResults<MyModelProxy>, ValueProxy {}

is how I remember having done this, and made the server generate BasePagingLoadResult objects containing the actual objects - haven't tried this in a while, but we do have SortInfo objects in working like this (we're experimenting with having @ProxyFor(SortInfoBean.class) on the SortInfo interface, clearly wont work for all cases).

I'll experiment with this issue this evening, see if we can get a concrete sample of this in the explorer.

[kospiotr]

So it is not possible to write generic

MyRfPagingResultsProxy for all paging results as you must specify MyModelProxy as an argument?

I would appreciate for any sample and in my opinion it's not an issue just limitation of Request Factory.

[kospiotr]

There is another solution but I would treat it as a last option. You can obtain List<MyModelProxy> and the rest in separated request batch:

MyContext ctx = factory.context();ctx.getList(offset, limit).to(new Receiver<List<MyModelProxy>>() { … });
ctx.getTotalCount().to(new Receiver<Integer>() { … });
ctx.fire();

But this method is really awkward.

[kospiotr]

and... how have you implemented code generation of

BasePagingLoadResult?

[Colin Alworth]

Sorry it has taken me to long to get back to you - been trying to see if there is a neater way around this issue.

First, yes, this is mostly an issue of how RequestFactory works. I saw the issue you filed at http://code.google.com/p/google-web-...detail?id=6967 and that it was closed in favor of the 'started' issue at http://code.google.com/p/google-web-...detail?id=5974. I don't see any active codereviews on this topic, so I am not sure how much attention it is getting - if I have time this weekend, I'll look into what it might take to fix this myself.

If you want to send the load config and load result objects over the wire, the only good solution for now seems to be creating matching proxy and bean types for each object you want to use. Config objects suffer the same basic issue if they wrap other config objects - even the ListLoadConfig will have this issue, as it contains a collection of SortInfo objects, which each must be translated to a SortInfoBean by RF. One can also create subinterfaces of the configs, as well as beans, or one could just send along the data that is able to be translated. In this code sample, I am doing both: creating a value/proxy pair for the load result, and requiring that the load config be taken apart before being sent over the wire:

public interface PostRequest extends RequestContext {
  @ProxyFor(PostPagingLoadResultBean.class)
  public interface PostPagingLoadResultProxy extends ValueProxy, PagingLoadResult<PostProxy> {
    @Override
    public List<PostProxy> getData();
  }
  
  public static class PostPagingLoadResultBean extends BasePagingLoadResult<Post> {
    public PostPagingLoadResultBean(List<Post> list, int totalLength, int offset) {
      super(list, totalLength, offset);
    }
  }

  Request<PostPagingLoadResultProxy> getPosts(int offset, int limit, List<? extends SortInfo> sortInfo);
}

> and... how have you implemented code generation of BasePagingLoadResult?

Can you explain this comment? I don't understand.