Thanks, John! Unfortunately, I just realized that there are more problems getting XHR available in Core. First, even though HTTPRequest is in package com.google.gwt.http, HTTPRequestImpl is over in gwt.user.client. Additionally, RequestBuilder depends on Timer, which is in user.
I'm thinking Timer could also reasonably be moved over to Core, and that should be the last of the dependency chasing. Thankfully, the Window class is already in Core. If this takes too too much longer, I'd like us to consider having runAsync only available in User. Maybe, though, we're getting close to getting XHR and its transitive dependencies available in Core.... On specific notes for the patch so far: On Fri, Jan 23, 2009 at 1:23 PM, John Tamplin <j...@google.com> wrote: > On Fri, Jan 23, 2009 at 11:09 AM, Lex Spoon <sp...@google.com> wrote: >> >> Here's the latest patch. Note that it includes an implicit test of >> the default impl via StringBufferDefaultImplTest, due to the way the >> patch modifies EmulSuiteUnknownAgent.gwt.xml. > > I didn't see any updates mentioned below so this is based on this patch. > > Have you considered the impact inheriting HTTP in Core for minimal client > applications that may not have inherited it before? Is there a way to only > pull this in if runAsync is used? If not, what about creating a deferred > binding property to disable runAsync for applicaitons that don't need it and > may not want HTTP inherited? The running idea has been that Core gets runAsync, but that if you don't use it then the relevant support will be removed. So, compile time would be affected, but not output size. I would like to not spend too much time, though, on optimizing Core-only applications. It's good to keep it working, but is it worth spending a lot of time making them work better? > I would prefer HTTPRequestImplStd (or similar) instead of NonIE6 Changed. > Why the replace-with in EmulSuiteUnknownAgent -- does that actually do > anything? Yes, that's used for testing. It overrides any other deferred binding for HTTPRequestImpl and gives all browser the default implementation. There's a class StringBufferDefaultImplTest that uses this module. It's arranged this way because the JUnit testing infrastructure pulls in UserAgent already and thus will use browser-specific deferred bindings for HTTPRequestImpl. To actually test the default implementations, these deferred bindings must be changed back. -Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
