I put some thought into this last night and there are some interesting questions raised:
By default, the IFrameLinker allows multiple modules to coexist on the same page. To replicate this with scripts, you need to ensure that all scripts are privately scoped. There are conflicts with privately- scoped scripts and dynamically-loaded code. You can mutate the global scope of a window, but I don't know of any way to add new identifiers to the scope of a function used as a private namespace after that function has terminated. It is possible to evaluate code within an existing private scope. As long as you can structure the symbol dependencies between runAsync modules such that it can be represented as a DAG, two fragments never providing visible identifiers for each other, you can load the various modules as a tree of scopes. I'm not deeply familiar with runAsync, so I don't know if it is always true. The worst-case end-result of loading 10 different fragments, each depending on symbols from the last n-1 loaded fragments would effectively be the equivalent of 10- deep nested scope chain. I don't know what effect this would have on performance. Here's a summary of the linking options that I know of. I've added in an alternative iframe linker that doesn't load HTML from a remote source, but dynamically constructs the iframe contents and injects the scripts into it: 1. Monolithic iframe (IFrameLinker): Supports multimodule: Yes Supports off-domain loading: No Supports runAsync: Yes Global namespace pollution: Only within the iframe 2. Dynamic iframe, injected with scripts, ie: create iframes dynamically with src="javascript:;" and document.write()ing an HTML document: Supports multimodule: Yes Supports off-domain loading: Yes Supports runAsync: Yes Global namespace pollution: Only within the iframe 3. Globally-scoped script: Supports multimodule: No Supports off-domain loading: Yes Supports runAsync: Yes Global namespace pollution: Yes 4. Privately-scoped script (XSLinker): Supports multimodule: Yes Supports off-domain loading: Yes Supports runAsync: Possibly, but with potential size/speed consequences Global namespace pollution: None Matt. On 25-Nov-09, at 12:39 AM, Ray Cromwell wrote: > > err, not explicit scope, I mean "predeclare all your symbols with > 'var' privarte scope". > > -Ray > > > On Tue, Nov 24, 2009 at 11:29 PM, Ray Cromwell > <cromwell...@gmail.com> wrote: > > IMHO, pollution of the global namespace is a big problem for general > purpose apps. It's ok to do it when you control everything (e.g. > Wave), but probably a bad idea for enterprise users who have a habit > of composing lots of small GWT modules on a single dashboard. We > probably need to support both explicit scope and polluting options, > and allow the developer to choose. > > -Ray > > > On Tue, Nov 24, 2009 at 8:33 PM, Scott Blum <sco...@google.com> wrote: > On Tue, Nov 24, 2009 at 9:39 PM, Matt Mastracci > <matt...@mastracci.com> wrote: > Hey Scott, > > I've ported hosted.html over to hosted.js a few times and it's not > actually a problem. The only significant differences between the two > files are s/parent/window/ and how you pass the name of the module > to the hosted-mode bootstrap script. Each version of the plugin > tested (Safari, FF and IE from a few months ago and recent Safari/FF > builds) has been able to work in this environment without > modification. > > I don't think the hosted-mode plugin would work with the privately- > scoped XSLinker today, but it definitely works with our modified > version that links the JS at the global scope. > > Okay, that makes sense to me. I think to really ship this, though, > we want the plugins to put their symbols into a private namespace. > Otherwise two modules on one page would step all over each other, > for example. > > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > > > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
