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
