You can define all your RPC methods to return a wrapper object that can
carry the RPC payload as well as any other data you want the server to
slip in to the client at the same time.
Using this technique, you need an extra async rpc class that most of
your code can call, and it handles the unwrapping behind the scenes as
well as providing a place for retry logic if you want it. (I use this to
force a login whenever a session times out, but the original rpc query
code never notices that between the original call and the response,
there's been a login screen displayed etc)
Something like this:
public interface ServiceAsync {
public Wrapper<Foo> getFoo(args, AsyncCallback<Wrapper<Foo>>callback);
}
public class MainService {
public void getFoo(args, AsyncCallback<Foo> callback) {
// do rpc
// unwrap result
// handle the data the server slipped in
// send Foo back to caller.
}
}
public class Wrapper<T> implements Serializable {
private T t;
private SomethingElseToSlipInToClient somethingElse;
public Wrapper(T t) { this.t = t; }
public T getValue() { return t; }
public void setValue(T t) { this.t = t; }
}
The negative side of this is that there's another place you need to add
boiler plate code every time you add an rpc method.
HTH,
Paul
[email protected] wrote:
> Using GWT as a CRUD front end for a database. We have found that most
> pages end up firing off multiple RPCs. At first each picklist needed
> it's own RPC so I wrote a client side "picklist" cache. This helped
> for picklists, but even so the picklist cache often it will often need
> to grab a missing picklist when an object is loaded (resulting in an
> extra RPC on a page/view load).
>
> Now there are a number of other things we have cached of client side
> that I would like for the server to be able to "push" to the client on
> the next RPC. Some of this is for security purposes ( a list of
> "actions" the user has, etc). If one of these lists changes the
> client should really be updated ASAP to reflect it.
>
> I'd thought throwing an exception that would cause the client to retry
> AFTER firing of a request to reload some of the security info but this
> has several downsides:
>
> 1. I would have to go through and trap the error at every RPC attempt
> and implement retry logic at every RPC also.
> 2. The first RPC that throws is a bit of a dead-end, it won't convey
> any data (although it could convey the original data requested I guess
> in an "Object data" field but that seems very hacky.
> 3. I was really hoping for something a bit cleaner.
>
> I'm guessing I could pull this off pretty easy if I switched to JSON
> for my RPC mechanism, but I'd really like it to stick with GWT-RPC.
> It would be nice if I could just do something like this:
>
> RpcBus mbus = new RpcBus( someRpcBusAsyncHandle );
> fooservice.app.bar( 1, mbus );
> fooservice.app.bar( 2, mbus );
> ...
>
> Which might produce XML that looked like this:
>
> <rpcbus>
> <rpc service="foo" method="bar">
> <arg name="blah" type="int">1</arg>
> </rpc>
> <rpc service="foo2" method="bar">
> <arg name="blah" type="int">2</arg>
> </rpc>
> ...
> </rpcbus>
>
> The result would be segmented also:
> <rpcbus_result>
> <rpc_result service="foo" method="bar" result_type="int">11</
> rpc_result>
> <rpc_result service="foo" method="bar" result_type="int">22</
> rpc_result>
> ...
> </rpcbus_result>
>
> Then i could bundle up multiple requests into one RPC and hopefully
> both aid responsiveness and simplify my client.
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
