Request Factory Grid Example - PostRequest Implementation Missing

I'm trying to implement a Grid using RequestFactory. My GWT implementation was scaffolded using Spring Roo. My EmployeeRequest class has the following method:

Request<List<EmployeeProxy>> findEmployeeEntries(int firstResult, int maxResults)

I am looking at the RequestFactory Grid example and I cannot get the typing right for the following call:
req.getPosts(loadConfig.getOffset(), loadConfig.getLimit(), loadConfig.getSortInfo()).to(receiver);

The getPosts method should be the equivalent of my findEmployeeEntries method but I believe it returns a different type. I cannot find the example implementation of the "PostRequest" class used for the example.

How should I map my findEmployeeEntries function to this getPosts function so that i can call .to(receiver) correctly?

Thanks!

The PostRequests interface looks like this:

Code:

---

@Service(value = PostService.class, locator = PostServiceLocator.class)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 PagingLoadResultBean<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);
}

---

I'll make sure it gets into the example as part of the next release. Note also that the source for all of the example app is available in the beta1 download.

In your case, I think you just need to remove the sortInfo, the third param, from your call, as your server doesnt seem to use it.

Thanks a lot. I was able to get it after some tinkering.

@thedamhattter

I'm trying to do the same thing: port the requestfactory grid sample to a roo-generated requestfactory/jpa back end. But this is my first try at working with gxt, so I am unfamiliar with the concepts of stores, loaders, loadconfigs, etc.

Can you post the code with which you got your sample working?

@Colin

There are many of us in the gwt community who use roo to quickly generate back-end jpa services with request factory. Is it possible that your team can post an example -- perhaps using ROO and the expenses.roo script -- of how to adapt the generated jpa/requestfactory service layer to your requestfactoryproxy?

Thanks for the suggestion, Will, we'll take a look into building an example with Roo in the new year. I have avoided Roo after my first encounter with it, after discovering how much boilerplate it generated, and how many modifications had to be made to make it do what I required. It has been almost a year and a half since I first tried, so I will try again, see if it has grown easier to use.

Wrapping a RF call with a DataProxy is pretty straightforward - that proxy instance can then be given to a Loader, and consumed by whatever will be initiating the loading of data. This should just be a matter of declaring a RequestFactoryProxy<C,M> instance, where C is the config data to be sent through the loader, and M is the return data to be sent back after the load.

The example at http://staging.sencha.com:8080/examp...estfactorygrid uses a proxy impl that looks like this

Code:

---

    RequestFactoryProxy<PagingLoadConfig, PagingLoadResult<PostProxy>> proxy = new RequestFactoryProxy<PagingLoadConfig, PagingLoadResult<PostProxy>>() {
      @Override
      public void load(PagingLoadConfig loadConfig, Receiver<? super PagingLoadResult<PostProxy>> receiver) {
        PostRequest req = rf.post();
        req.getPosts(loadConfig.getOffset(), loadConfig.getLimit(), loadConfig.getSortInfo()).to(receiver);
        req.fire();
      }
    };

---

A RequestContext is created, a request is added, and the request is fired. By wrapping the call in a DataProxy instance like this, GXT code can genericly call it, and your services which are wrapped by Roo can be consumed by the client. A further step using Roo's generation could be to build these proxies as well, though there could be ambiguity with regard to which param is which (offset, limit), unless you pass the entire load config to the server (which doesn't work well with current versions of GWT, see http://www.sencha.com/forum/showthre...ctory-question and http://code.google.com/p/google-web-...detail?id=5974 for why this doesnt work well, what is being done about it).

My application is highly structured and it would take too much space to post it all. This is the initial client side code stub that I wrote to verify the client side. In my application now things are abstracted and separated into views vs activities, etc.

Code:

---

interface EmployeeProxyProperties extends PropertyAccess<EmployeeProxy> {
    ModelKeyProvider<EmployeeProxy> id();
 
    ValueProvider<EmployeeProxy, String> displayName();
    ValueProvider<EmployeeProxy, String> jobFunction();
  }


final ApplicationRequestFactory rf = GWT.create(ApplicationRequestFactory.class);
    rf.initialize(new SimpleEventBus());
 
    RequestFactoryProxy<PagingLoadConfig, PagingLoadResult<EmployeeProxy>> proxy = new RequestFactoryProxy<PagingLoadConfig, PagingLoadResult<EmployeeProxy>>() {
      @Override
      public void load(PagingLoadConfig loadConfig, Receiver<? super PagingLoadResult<EmployeeProxy>> receiver) {
        EmployeeRequest req = rf.employeeRequest();
        req.getData(loadConfig.getOffset(), loadConfig.getLimit(), loadConfig.getSortInfo()).to(receiver);
        req.fire();
      }
    };
@Override
  public Widget asWidget() {   
  PagingLoader<PagingLoadConfig, PagingLoadResult<EmployeeProxy>> loader = new
  PagingLoader<PagingLoadConfig, PagingLoadResult<EmployeeProxy>>(
                    proxy);
 
    EmployeeProxyProperties props = GWT.create(EmployeeProxyProperties.class);
 
    ListStore<EmployeeProxy> store = new ListStore<EmployeeProxy>(props.id());
    loader.addLoadHandler(new LoadResultListStoreBinding<PagingLoadConfig, EmployeeProxy, PagingLoadResult<EmployeeProxy>>(
        store));
 
    final PagingToolBar toolBar = new PagingToolBar(50);
    toolBar.getElement().getStyle().setProperty("borderBottom", "none");
    toolBar.bind(loader);
 
    ColumnConfig<EmployeeProxy, String> forumColumn = new ColumnConfig<EmployeeProxy, String>(props.displayName(), 150, "DisplayName");
    ColumnConfig<EmployeeProxy, String> usernameColumn = new ColumnConfig<EmployeeProxy, String>(props.jobFunction(), 150,
        "Job Function");
 
    List<ColumnConfig<EmployeeProxy, ?>> l = new ArrayList<ColumnConfig<EmployeeProxy, ?>>();
    l.add(forumColumn);
    l.add(usernameColumn);
 
    ColumnModel<EmployeeProxy> cm = new ColumnModel<EmployeeProxy>(l);
 
    Grid<EmployeeProxy> view = new Grid<EmployeeProxy>(store, cm) {
      @Override
      protected void onAfterFirstAttach() {
        super.onAfterFirstAttach();
        Scheduler.get().scheduleDeferred(new ScheduledCommand() {
          @Override
          public void execute() {
            loader.load();
          }
        });
      }
    };
    view.setLoader(loader);
FramedPanel cp = new FramedPanel();
    cp.setHeadingText("RequestFactory Grid Example");
    cp.setPixelSize(500, 400);
    cp.addStyleName("margin-10");
 
    VerticalLayoutContainer con = new VerticalLayoutContainer();
    con.setBorders(true);
    con.add(view, new VerticalLayoutData(1, 1));
    con.add(toolBar, new VerticalLayoutData(1, -1));
    cp.setWidget(con);
 
    return cp;
  }

---

The serverside is trickier

Code:

---

public static EmployeePagingLoadResultBean getData(int offset, int limit, List<? extends SortInfoBean> sortInfo) {
            List<Employee> employees = entityManager().createQuery("SELECT o FROM Employee o", Employee.class).getResultList();
            if (sortInfo.size() > 0) {
              SortInfo sort = sortInfo.get(0);
              if (sort.getSortField() != null) {
                final String sortField = sort.getSortField();
                if (sortField != null) {
                  Collections.sort(employees, sort.getSortDir().comparator(new Comparator<Employee>() {
                    public int compare(Employee p1, Employee p2) {
                      if (sortField.equals("displayName")) {
                        return p1.getDisplayName().compareTo(p2.getDisplayName());
                      }
                      return 0;
                    }
                  }));
                }
              }
            }
         
            ArrayList<Employee> sublist = new ArrayList<Employee>();
            int start = offset;
            int actualLimit = employees.size();
            if (limit > 0) {
              actualLimit = Math.min(start + limit, actualLimit);
            }
            for (int i = offset; i < actualLimit; i++) {
              sublist.add(employees.get(i));
            }
            return new EmployeePagingLoadResultBean(sublist, employees.size(), offset);
          }
         
          public static class EmployeePagingLoadResultBean extends PagingLoadResultBean<Employee> {


                        private static final long serialVersionUID = 1L;
                       
                        public EmployeePagingLoadResultBean() {
                            super();
                    }
                       
                public EmployeePagingLoadResultBean(List<Employee> list, int totalLength, int offset) {
                  super(list, totalLength, offset);
                }
          }

---

Good luck!

Thanks for sharing, thedamhattter. Consider letting the database do the sorting, based on the string value passed in. It should be sorted to make this safe, to prevent sql injection. This will allow you to limit the data passed from the db into java, as the db can do the limit/offset work.

Thanks for the tip. There is still plenty of work to do!

The sorting code was adapted from the grid example. I'm sure that for a production application, it would be better to have the database do the sorting. I am using hibernate + mysql. Are you suggesting that the sorting be done through SQL by augmenting the query or is there another mechanism for doing this?

I'm not a database expert, and certainly not a hibernate expert, but from my past experiences with getting the app server and the db to work as efficiently as possible, I've found that the DB should pass as little data along to the app server as is possible - creating, sorting those objects in Java (or most/all other servers) will be more expensive than letting the database manage it, as that is what it does best. To do this, the change will result in different SQL being sent to the server, but whether that change is in the sql you write, or if your ORM tool can do it for you, I can't say for sure.

That said, "premature optimization is the root of all evil" (http://en.wikiquote.org/wiki/Donald_Knuth) - if your expected dataset is small enough, it shouldn't be an issue. If it is smaller still, you could let the client even do the work - paging may not even be necessary...