Yeah I could to that but it has a couple of significant downsides. We already have a little JSON frontend to the services for the PHP crowd so I'm guessing we will just polish it a bit and use that. I hate to mix two different RPC mechanisms in one app but I just can't see how else to do this without hacking GWT which I really don't have time for just at this moment ;-)
On Apr 28, 11:45 am, Paul Robinson <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
