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 Le mercredi 16 juillet 2014 11:28:33 UTC+2, Thomas Broyer a écrit : > > > > 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) > > >> >> Il giorno lunedì 12 novembre 2012 17:54:58 UTC+1, Thomas Broyer ha >> scritto: >>> >>> >>> >>> 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 >>> <http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/core/client/ScriptInjector.html> >>> >>> 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–) >>> >> -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
