You could, but the call sites no longer look like plain RPC method calls if I understand you. The cleanest solution I've come up with so far is to just override the ServiceInterfaceGeneratorProxy and replace the RemoteServiceProxy with one that has the proper doInvoke() method, but it feels hacky, much like subclassing RequestBuilder and trying to pretend it isn't an XHR (which actually seems impractical given constraints on the Request base class) It's not the end of the world, and I suppose you could include something like my solution in the Gadget module in GALGWT, but it is worth noting that doing cross-domain RPC or RPC from within containers does appear to be a common question. -Ray
On Thu, Mar 19, 2009 at 7:19 AM, Scott Blum <[email protected]> wrote: > Ray-- can't you cast the rebind result to SerializationStreamFactory and > use createStreamWriter()/createStreamReader() to throw your own party? > > > On Wed, Mar 18, 2009 at 10:34 PM, Ray Cromwell <[email protected]>wrote: > >> >> >> On Wed, Mar 18, 2009 at 6:11 PM, BobV <[email protected]> wrote: >> >>> On Wed, Mar 18, 2009 at 7:44 PM, Ray Cromwell <[email protected]> >>> wrote: >>> > My only criticism of this design is that it only captures a part of the >>> use >>> > cases where the transport mechanism needs override. That is, it helps >>> in >>> > cases where one is making HTTP requests, and needs to modify HTTP >>> request >>> > parameters or the body, but it leaves out the cases where one can't >>> make >>> > direct requests (using XHR). The RequestBuilder stuff is very tightly >>> bound >>> > to XHR. >>> >>> It would be possible (if baroque) with this API to substitute in a >>> "ScriptTagRequestBuilder" implementation in the doCreate() method. >>> >> >> >> I originally tried this approach, but ran into the problem that the >> Request class is not abstract enough or decoupled from XHR to pull it off, >> as well as being difficult to subclass due to many private/package-protected >> methods. >> >> >>> I'll make the unsubstantiated claim that non-XHR transport is a small >>> enough portion of the user-base to avoid complicating the client-side >>> API as long as you can make that non-XHR transport look like XHR by >>> creating a RequestBuilder subclass. >> >> >> I don't have any data to refute that, but I'd offer that two of Google's >> major properties APIs: OpenSocial and FriendConnect flat out require >> non-XHR, and this touches services with export these APIs (now Orkut, Gmail, >> iGoogle, GFC, among others). And that anyone who attempts to create a >> cross-domain GWT application that uses RPC will run into it, to the extent >> that many GWT users just dump RPC and resort to JSON + script tag injection. >> It's one of the often repeated blog tutorials. >> >> Maybe there's a way to work around the Request class issue. >> >> -Ray >> >> >>> >>> -- >>> Bob Vawter >>> Google Web Toolkit Team >>> >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
