Perhaps there might be cases where shard-vs-non-shard versions would have to be loaded by the selection script based on the environment. This could be due to container issues (social network containers), or more exotic scenarios like running code inside some Flash VM. I have already run into the former situation with Google Gadgets, where shards need to be either be loaded by the gadget container's proxy/cache, or via gadget.io.makeRequest(). The benefit of using deferred binding properties is that you can compile two seperate versions that load differently in different environments.
To achieve the same effect with command line parameters, you need to use separate build scripts, deploy the artifacts to different URLs, use different host pages that source different selection scripts. For me personally, as someone who ships "exported" XS hosted GWT applications, the former has the following benefit: 1) I give my users 1 single URL, they <script src="...">, the selection script does the rest vs 2) I deploy multiple versions of my app to different URLs, and write extra documentation explaining to users when and where to pick each one. I am not too wedded to either approach, since I can deal with both. The big downside of using deferred binding is it would increase compilation times, which are already slow enough. -Ray On Tue, Dec 16, 2008 at 2:24 PM, Sam Gross <colesb...@gmail.com> wrote: > What's the reasoning for preferring deferred binding properties? > I would think that a option to disable sharding globally is > more appropriate as a compiler flag than as a module property. My thinking > is that since a module encapsulates functionality, it should avoid causing > global program changes, such as disabling sharding in other modules. > I understand that linkers, which are configured as module properties, affect > global program changes, but I'm not sure that is sufficient reason for > further breaking encapsulation. > > Will adding this as a module property make it more difficult to drop XML > module files in favor of annotations in the future? > Regards, > Sam > On Tue, Dec 16, 2008 at 3:09 PM, Lex Spoon <sp...@google.com> wrote: >> >> On Mon, Dec 15, 2008 at 4:09 AM, BobV <b...@google.com> wrote: >> > I was trying to demonstrate the practical difference that runAsync >> > would make when compared to a monolithic deployment to someone today, >> > and there was no simple way to turn off runAsync that wasn't the >> > -disableAggressiveOptimizations flag. >> > >> > This patch adds an undocumented flag -disableRunAsync that just >> > disables code-splitting when compiling an app. >> >> FWIW, the *implementation* LGTM. The open question is about whether >> to keep it as a command-line option or go to a module-file solution. >> >> >> Lex >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
