Passing Parameters in GWT RPC (Client-side)

Continued from GWT RPC

---

The GWT RPC tutorials provide the simple case of passing and receiving String objects. However, in most, if not all, practical cases, programmers need to pass a set of parameter-value pairs between HTTP communicants. In this case, between communicants of the communion of RPC over HTTP.

TableMgr bears in itself an example how to pass parameters over the RPC/GWT/HTTP (RPC over GWT over HTTP) communion.

For TableMgr source code, refer to
http://code.google.com/p/synthfuljava/source/browse/#svn/apps/GData Table Manager,

and for the library elements it uses, refer to
http://code.google.com/p/synthfuljava/source/browse/#svn/trunk.

Do not copy code from this page, as it would contain line-breaks and exclude lines left out for brevity that would break the code, but get them drectly from the google code project listed above.

TableMgr uses a HashMap as the datatype being passed. A HashMap is the best choice because it allows values to be mapped to parameter keys.


GWT client-side code

package org.synthful.gwt.http.servlet.client;
import java.util.HashMap;
import com.google.gwt.user.client.rpc.RemoteService;

public interface HashedParameterService
extends RemoteService
{
 String doServiceResponse(
  HashMap<String, String> input);
}

The interface HashedParameterService is a generic service declaration interface (provided by the courtesy of this author) which anyone could use, but if you use it with GWT-provided server side RemoteServiceServlet, your servlet would need to provide the method

String doServiceResponse(
 HashMap<String, String> input);

GWT applications in accessory to using this framework is restricted to having this method as the RPC procedure being called.

Or, you could copy it and rename the method to a name of your liking. However, my intention for it was not to provide a generic service declaration interface, but for a more sinister intention. It is to subvert the RemoteServiceServlet provided by GWT so that I could have JSPs, rather than plain servlets, implement it to service RPC requests. This would be explained later in the server-side part.

Wait a minute, shouldn't the service declaration interface contain the RemoteServiceRelativePath directive to tell the GWT compiler the URL that would service its RPC request? Therefore, to keep this interface generic, we introduce an extra layer of interface.

package com.blessedgeek.gwt.gdata.client;
import
org.synthful.gwt.http.servlet.client.HashedParameterService;
import
com.google.gwt.user.client.rpc.RemoteServiceRelativePath;
@RemoteServiceRelativePath("TableActionService.gwtrpc.jsp")
public interface TableMgrService
 extends HashedParameterService
{}

TableMgrService would be the actual interface implemented by the RPC client, but the server side would still implement its super-interface HashedParameterService. The corresponding client and server sides do not actually have to implement the same interface but interfaces of the same signature.

The companion async-response request interface to that is

package org.synthful.gwt.http.servlet.client;
import java.util.HashMap;
import com.google.gwt.user.client.rpc.AsyncCallback;

/*
* @gwt.TypeArgs parameters <java.util.HashMap 
<java.lang.String,java.lang.String>>
*/
public interface HashedParameterServiceAsync
{
 void doServiceResponse(
  HashMap<String, String> parameters,
 AsyncCallback<String> callback);
}

Note that both of them declares the same HashMap<String, String> parameters argument.

---

Continue next Passing Parameters in GWT RPC (Server-side)