Sorry for the double reply but I decided to file an issue for build flags to control the optimization level to allow for faster compilation time during development. http://code.google.com/p/google-web-toolkit/issues/detail?id=2944
On Oct 4, 10:24 pm, TrashHalo <[EMAIL PROTECTED]> wrote: > I don't think we (GWT Developers) would care too much about long > compilation times if we did not have to encounter them on a daily > basis. If you have been tracking the issue tracker over the past year > you would know that the great majority of compilation time is a result > of each optimization pass. Last year I requested the feature to > disable/enable optimization passes through flags passed in to the > compiler (http://groups.google.com/group/Google-Web-Toolkit/ > browse_thread/thread/349b06c86440bd7b/4a1793fc70fb1d56? > lnk=gst&q=trashhalo#4a1793fc70fb1d56) > > Bruce responded "until there are some really strong concrete reasons > to expose fine-grained switches (other than "turn them off/on"), we > err on the side of keeping things simple." I hope you would agree that > disabling time expensive optimizations during development would be a > "concrete reason" for providing developers with the option to disable > certain optimizations. When I originally made that post I had spent > some time digging through the compiler source code to better > understand how the optimizations are implemented. > > Back then (and I would hope this is still the case today) each > optimization type/pass was encapsulated into its own object. The > compiler then passed the payload into each of these optimizer objects. > Because of this setup adding compilation flags to skip certain > optimizations would be trivial. These optimizations could be reenabled > for test or production builds. > > On Oct 4, 9:49 pm, NullPointer <[EMAIL PROTECTED]> wrote: > > > Further to this topic, it makes me wonder on how I design a larger > > application using GWT. My application has as much as 200-300 > > screens(each screen a composite panel contains anything more than > > 500-1000 widgets in different tabpanels, popups etc) and how to load > > all these screens from a single menubar. > > > #1. Organizing all the code for 200 screens in to different GWT > > modules and makig the module containing the Menubar depend on these > > modules and loading the individual screens by instantiating the > > respective composite panel and adding to the main panel does not help > > bring down the JavaScript size. Irrespective of how you organize your > > modules, there will still be one JavaScript generated for every > > browser and that JavaScript will contain the code for all the classes > > in all these separate modules. For an application of the size of mine, > > the size of JavaScript is 15MB. Correct me if i am wrong > > > #2. Second option i have is to organize the code for these 200 screens > > in to different modules and have different HTML page for each of these > > group of screens calling the respective entrypoints. The module > > containing the Menubar will not depend on these child modules but uses > > a GWT FramePanel and calls the appropriate HTML with relevant > > parameters and load the respective screen. But this defeats the AJAX > > pattern and there will be a number of round trips to the Server to > > load each separate screen. > > > Any help on how to tackle the JavaScript size and how to load 200-300 > > different screens from the same Menubar will be much appreciated. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
