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. On 24-Nov-09, at 5:46 PM, Scott Blum wrote: > I think this is a good direction to be heading in. It's a bit non- > trivial, though, because the plugin expects to be nested in an > iframe. I'm sure that's solvable, but it will be some work. > > On Tue, Nov 24, 2009 at 6:38 PM, Matt Mastracci > <matt...@mastracci.com> wrote: > Hey all, > > If I recall correctly, the original reason that GWT used iframe- > wrapped scripts was to work around the buggy compression of Javascript > some early versions of IE (example: > http://support.microsoft.com/default.aspx?scid=kb;en-us;823386&Product=ie600) > . > > The number of users on IE 6 SP1 is likely fairly small right now and > at some point, IE6 is going to drop off the map entirely. I wonder if > it might be a good time for GWT to consider the switch to raw JS files > and consider IE6 SP1 as a "special case" to work around. > > There's a number of advantages to serving raw JS: > > - You can serve it from a CDN (we do this right now, but it > requires a lot of work on our side to track the hosted mode code) > - It doesn't require an additional browser rendering context > - XSLinker is no longer a special case: wrapping the code in a > closure to prevent namespace pollution can be a configuration property > - Better guarantees on parallel downloads for loading leftover and > exclusive fragments simultaneously > - Window events no longer need selection-script support to be > hooked up (to work around the IE security bugs) > - Less magical overall: a design closer to that of other modular JS > toolkits > > It seems like the post-2.0 GWT codebase would be a reasonable time to > proceed along this path. I've been using this approach for some time > and it's been working very well. > > Thoughts? > > Matt. > > -- > 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
