GWT Cross Site Iframe Linker and Script Tags

[Daniel]

Hi,

can someone please explain to me the technical details why the xsiframe Link can not compile GWT apps which load <script> tags in their .gwt.xml module?

It gives the following error:

[ERROR] The Cross-Site-Iframe linker does not support <script> tags in the gwt.xml files, but the gwt.xml file (or the gwt.xml files which it includes) contains the following script tags: 

.....

In order for your application to run correctly, you will need to include these tags in your host page directly. In order to avoid this error, you will need to remove the script tags from the gwt.xml file, or add this property to the gwt.xml file: <set-configuration-property name='xsiframe.failIfScriptTag' value='FALSE'/>

The error message already tells the workaround, so I know how to compile it. Still, I'm wondering about the reason why it can't compile with <script> tags? I understand the same origin policy problem with the regular Iframe Linker and XHR. But including a script tag doesn't require XHR. So whats the technical reason behind this?

Thanks

[Thomas Broyer]

It's not about the SOP (not directly at least), it's about how the *.cache.* script is (or can be) injected.

<script>s in gwt.xml are guaranteed to be fully loaded by by the time the onModuleLoad is called, so you can directly make calls to functions or objects declared in those scripts. This is done by using document.write()s and some trickery to make it work in all browsers. The xsiframe linker no longer uses document.write, so it couldn't guarantee the loading order; as a consequence, scripts are simply not injected (at all); they fail the build by default, or can be ignored with the xsiframe.failIfScriptTag configuration property.

[Daniel]

Thanks for the explanation.

I find this very interesting. This means I'll be able to extend the CrossSiteIframeLinker Linker and overwrite the fillSelectionScriptTemplate() function to include all required scripts with sth like document.write() or document.getElementsByTagName("head")[0].appendChild()

And to guarantee that they are present during onModuleLoad() there should be a couple of workarounds, like checking in every entry point module if scripts are ready (with sth like typeof LibraryName === "undefined") and if not postpone startup until they are ready.

Or maybe taking a closer look at the regular IFrameLinker. From what I see right now it basically uses document.write("<script defer="defer">module.onInjectionDone('module')</script>") and then calls maybeStartModule() which hopefully will have code I can reuse.

And the reason google didn't include this in their CrossSiteIframeLinker is because they didn't want to use document.write() for this linker?

[skrat]

This sucks great time, now that devmode plugins have been abandoned (surprise!), and Super Dev Mode was forced onto us, xsiframe became a must, and all the GWT libraries and apps that use script tags are not working anymore. What's wrong with document.write anyway? I'm really angry now with Google, and we're going to rewrite the app with JS, Backbone, jQuery, who knows. At least stuff won't break because of ridiculous developer decisions. Thanks Google

[Thomas Broyer]

On Friday, September 28, 2012 4:36:41 PM UTC+2, skrat wrote:

This sucks great time, now that devmode plugins have been abandoned (surprise!),

Are you kidding?!

Brian spent days (weeks?) releasing the plugin for Firefox 15 (there was more changes from Mozilla's side than for previous releases) and fixing the plugin for Chrome, porting it to manifest v2 so that it can be submitted on the Chrome Web Store (he's not done yet, only the linux binaries have been recompiled for now).

Please have a look at the SVN <http://code.google.com/p/google-web-toolkit/source/list?path=/trunk/plugins/> and/or http://gwt-code-reviews.appspot.com before making such assertions.

[googelybear]

I have the same error when running the code server and this limitation effectively prevents me from using superdevmode, as in my case the problem is with an external library that I include which then uses the <script> tag in its own module xml.

Also not being able to use <script> in the module xml breaks encapsulation of modules, as I know have to include all scripts from all libraries in my host page (for me that's implementation details that I don't care about) . I know superdevmode is still experimental and seriously hope that this will be fixed. In the meantime does anyone have an idea how to work around this? Besides manually patching a 3rd party library...

cheers,

Mike

On Monday, July 23, 2012 4:33:01 PM UTC+2, Daniel wrote:

[Thomas Broyer]

On Monday, November 12, 2012 4:55:58 PM UTC+1, googelybear wrote:

I have the same error when running the code server and this limitation effectively prevents me from using superdevmode, as in my case the problem is with an external library that I include which then uses the <script> tag in its own module xml.

Also not being able to use <script> in the module xml breaks encapsulation of modules, as I know have to include all scripts from all libraries in my host page (for me that's implementation details that I don't care about) .

There's ScriptInjector to encapsulate loading within the module's code.

 

I know superdevmode is still experimental and seriously hope that this will be fixed. In the meantime does anyone have an idea how to work around this? Besides manually patching a 3rd party library...

In your module that enables the SuperDevMode hooks, add the failIfScriptTag configuration property and add an entry-point that uses ScriptInjector to load the 3rd-party scripts. The 2 entry points (from your app, inherited GWT module, and from the SuperDevMode-specific module) will both be executed; beware though that onModuleLoad will be called *before* the scripts are loaded, so your code that depends on them has to wait a bit… There are a couple ways to workaround this if really needed (but it's a bit more "invasive" for your app; that being said, xsiframe is the future, and might becomes the default at some point, so better be prepared –and update your 3rd-party libs–)

[googelybear]

Thanks for the pointer to the ScriptInjector, didn't know that before.

It's not that I don't want to update my libraries, but in my case the 3rd party library I am using to include flash content (gwt2swf) seems to be no longer maintained. So I guess I have to do it by myself using the ScriptInjector :-)

[gabriele.prandini]

This problem is blocking me from use superdevmode

i have many 3th library, also gwt-ext... and gwt-ext have some script tag on his gwt.xml

so sad :-(

[Thomas Broyer]

On Wednesday, July 16, 2014 11:06:43 AM UTC+2, gabriele.prandini wrote:

This problem is blocking me from use superdevmode

i have many 3th library, also gwt-ext... and gwt-ext have some script tag on his gwt.xml

so sad :-(

As the error message says: add <set-configuration-property name='xsiframe.failIfScriptTag' value='FALSE'/> to your gwt.xml and put all the needed <script> tags in your HTML host page (or inject them using ScriptInjector from your onModuleLoad, deferring everything else until after the scripts have been loaded)

[Etienne Lacazedieu]

Hi,

I'm preparing a big switch (GWT2.3 to 2.6.1, which may change to 2.7.0 depening on the final release date), and I'm having trouble with the xsiframe linker.. I have no problems with adding script> tags in the HTML file.

Actually, I wrote a linker (a subclass of CrossSiteIframeLinker), which outputs the list of JS files to a properties file.

On the server side, a class reads this file to add <script> tags (we use JSP).

My problem is that we have a rather complex integration process, with several GWT applications on the same page.

• a Container app, which creates Desktop-like UI, and exposes some JS native API to interact with other apps.
  
• several Functional apps, each one containing one or more "functional modules". Each functional module description is "injected" to the container app, which creates a launcher command. Invoking the command (done in the container app) triggers the creation of the functional module UI (done in the functional app). When this function returns, the container grabs the new DOM element and creates a Window UI around it.

My problem with the XSI linker is that I cannot get it to work as it did before.. 

In my sample deployment, the container is called SampleGWTContainer, and the functional app is called SampleApplication.

I have the following error in the console : 

$wnd.SampleApplication.runAsyncCallback2 is not a function

The odd thing is that when I start SuperDevMode, and recompile SampleApplication, it works.

If I recompile SampleGWTContainer, I have the same error.

I still have to try to remove the split point, to make know if it is a Linker or a Code Splitting related problem..

Any idea that might help me out? 

Thanks a lot,

Etienne

[Etienne Lacazedieu]

Well, it was a Code Splitting problem.

Both SuperDevMode and DevMode works fine with the new linker.

[Greg]

Hi

I know it's an old thread but I used few hours to quickly implement a linker and special entry point class that uses script tags from gwt.xml files and injects them automatically using ScriptInjector. There are few changes required in EntryPoint classes but they are not that intrusive.

Could you tell me if such approach is sensible? Do you see any problems it could cause (except difference in performance - scripts have to be loaded one after another instead of almost concurrently).

Link to repo: https://github.com/metteo/gwt-si

Greg