On Fri, Aug 7, 2009 at 11:11 AM, Lex Spoon<[email protected]> wrote: > Okay, I recently wrote a test for runAsync lightweight metrics, but -- > oops -- that test fails in draft mode. In draft mode, no code > splitting happens, so no events are generated, and so the test > rightfully complains. So, what should be done? > > I'm thinking to have draft mode generate some different events, and am > wondering what people think. > > My first thought was to leave the events alone, because after all > there are no actual downloads in draft mode. However, there are > several problems with that approach: > > 1. The test really should fail if no events are generated in regular > compilation modes. So it wouldn't be good to simply change the test > to tolerate a complete lack of events. > > 2. It's awkward to have a test that only runs in certain compilation > modes. The list of exceptions would have to live somewhere, and where > would that be? > > 3. It's also awkward to have the test disable itself, because it needs > to query some API to figure out whether code splitting really > happened. What API would that be? "Am I in draft compile mode"? > "Did code splitting happen for real"? I can't think of an API that > wouldn't be fragile.
I don't think its terribly yucky to add a GWT.isRunAsync() (pick your favorite name) method the way we have GWT.isScript() and a host of other little similar static methods in the GWT class. > It's fully intended that the compiler is > flexible in the kinds of optimization it does, and it should be > possible for the code splitter to have its own decision making as > well. It would be better if this test were robust against such > changes. Further, the API would be hard to keep private to the test; > application code might start using it, thus locking GWT into > supporting it for some amount of time. > > So, instead of enabling the test selectively, how about generating a > different event when in draft compile mode? The current event > sequence for calling a single runAsync is as follows: > > - leftoversDownload -- download of the leftovers fragment > - download1 --- download of code for split point 1 > - runCallbacks1 -- run the callbacks for split point 1 > > > In draft compile mode, maybe the events could be like this: > > - codeAlreadyLoaded1 -- code for split point 1 requested but already present > - runCallbacks1 -- run the callbacks for split point 1 > > > I could then update the test to tolerate either sequence. > > > Thoughts? > > Lex > -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
