Perhaps you want only a single script output or you want to use the application in a cross-site manner (in a different URL). In those and other cases, you can use GWT’s linkers to help.
If you look in GWT’s Core module and those it references, you’ll see several linkers defined:
■ IFrameLinker—This is the default linker and creates the bootstrapping process
already described, loading the GWT application into an iFrame (it’s named std).
■ SingleScriptLinker—This produces a single script output where all code is in the nocache.js output (it’s named sso).
■ XSLinker—For use when you need a cross-site-compatible bootstrap sequence (named xs).
■ CrossSiteIframeLinker—This uses an iFrame to hold the code, with a script tag being responsible to download it for use when you need a cross-site-compatible output.
■ DirectInstallLinker—This is another cross-site-compatible approach. According to the documentation, this adds a script tag to the iFrame rather than downloading as a String and then inserting into the iFrame.
We mention these so you know you have some options, and we won’t explore them further.
Most of the time the standard linker is what you need, so there’s no need to fiddle.
If you do find you need to use a different linker—maybe you’re creating code that will
be embedded into another person’s site—then you can change the linker by adding it
into your module definition. For example, to use the single-script linker you’d add
<add-linker name=”sso” />
The difference shown in figure above is that the single-script linker has put all the
a mouthful!), whereas in the standard output that file contains only the bootstrap
code, which then selects the most appropriate cache.html file.
In my project, we use xs because our app need to access other iframe data within some different domain in non-localhost environments. Then we overwrite this value with std in a local module for dev mode.