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 -~----------~----~----~----~------~----~------~--~---
