Updating GWT libraries for supporting xsiframe

[Sebastián Gurin]

I'm the author of some GWT libraries wrapping some JS libraries like YUI, raphaeljs, sizzlejs, etc. In this GWT libraries I need to include the JS files and until now I'm doing this using <script src="jsLibrary.js"></script> in my libraries gwt.xml. This way the end user of my libs do not have to worry about getting or loading the JS library at all, just <inherith> my library and it is ready to work.

But <script> in gwt.xml is not supported by the new xsiframe linker. As I understand from previous discussion and documentation, there are two possible solutions:

1) First solution: let the user be responsible of including the aLibrary.js file in its html host page. This adds extra work to the end user: he has to download the .js minified file and include it on the html host page.

2) Second solution: use a tool like ScriptInjector for loading aLibrary.js file dynamically. With this solution I release the user of the responsabilities of having to get the .js file and put it on the host page, but adds an extra step for our users. For example, in my libraries  "getting started" guides like http://code.google.com/p/gwtsizzle/wiki/GettingStarted the user is able to use the Java API directly withtout loading anything, but now he must first load the "library" async for using it, like this:

MyLib.load(new MyCallback(){
    public void loaded(){
        //now start using the API
    }
})

This two solutions adds extra work to the end user compared to my current solution of symply using <script src="aLib.js"></script> in my library's gwt.xml file. So my question is, am I missing something ? a third solution that I didn't contemplate ? Or simply updating my GWT wrapper libraries to support xsiframe linker will add extra work to my libraies end users ?

Regards and thanks in advance.

[Colin Alworth]

Greetings from IRC - glad to see you are continuing with this idea.

It could be worth considering inlining the sizzle.js code as JSNI to avoid the extra .js file at all, either from the module file or from the base html file. This has the additional constraint/advantage that you'll need to modify the code slightly to allow it to work from within GWT (i.e. document -> $doc, window -> $wnd), and remove any `with` statements. At that point it should behave well from within GWT, though the closure compiler might give it some grief. This is sort of a 3) to your list.

2b) Use ScriptInjector plus a TextResource - no async, as the code will be compiled in, and no need to rewrite to use $doc/$wnd and avoid with - the compiler will also leave this code alone, as it looks like a string. Like the option above (and unlike 1 and 2) this will still result in the sizzle.js file to be compiled into the <giant hash name>.cache.html file, minimizing the number of downloads required.

The chief advantage I see in 3) over 2b) is that it paves a smoother path toward making a proper 'port' instead of a 'wrapper' or 'bridge' (lets leave the naming to the other thread...) - you can slowly rewrite JS to Java methods, or break the JS into multiple JSNI methods depending on what they do and how you want to access them. Another advantage is that the compiler can at least do *something* to JSNI, whereas it will leave 1), 2), and 2b) alone and unoptimized - this could even allow you to source in unobfuscated JS in the JSNI, and let GWT do the minimizing for you - and if you can make Closure play nice, you'll even get strings like Sizzle rewritten too.

In contrast, 2b) gives you an easier first step forward, no async messiness, and no external dependencies or extra wiring that the library's users will need to do. Still worthwhile, but a different goal to follow.

[Sebastián Gurin]

Hi niloc, thank you very much for your ideas. In my case your solution 3) (inlining the js) is not what I want. In my case I want two things:

1) easy to the end user (it shouldn't have to worry about adding thirdLibrary.js file anywhere)
2) easy for me to update to new versions of thirdLibrary.js. Do not have to mantain my own version of thirdLibrary.js.

So for me your 2b) solution is what I wanted and worked fine. See how I'm loading sizzle.js now:
http://code.google.com/p/gwtsizzle/source/browse/trunk/gwtsizzle/src/org/sgx/gwtsizzle/client/Sizzle.java#28

Note that for some unknown reason setWindow($wnd) was required for this to work!

Thank you again!

[Thomas Broyer]

On Sunday, January 20, 2013 3:14:50 PM UTC+1, Sebastián Gurin wrote:

Hi niloc, thank you very much for your ideas. In my case your solution 3) (inlining the js) is not what I want. In my case I want two things:

1) easy to the end user (it shouldn't have to worry about adding thirdLibrary.js file anywhere)
2) easy for me to update to new versions of thirdLibrary.js. Do not have to mantain my own version of thirdLibrary.js.

So for me your 2b) solution is what I wanted and worked fine. See how I'm loading sizzle.js now:
http://code.google.com/p/gwtsizzle/source/browse/trunk/gwtsizzle/src/org/sgx/gwtsizzle/client/Sizzle.java#28

Note that for some unknown reason setWindow($wnd) was required for this to work!

How about ScriptInjector.TOP_WINDOW instead of your JsUtil.window().cast() ? (I think the reason is explained in the javadoc)

[Sebastián Gurin]

On Sunday, January 20, 2013 2:49:27 PM UTC-2, Thomas Broyer wrote:

How about ScriptInjector.TOP_WINDOW instead of your JsUtil.window().cast() ? (I think the reason is explained in the javadoc)

That did the trick too. Thanks!

[Hannes]

I'm having the same use case, so 2b seems to be the right choice for me too.
But since this topic is two years old now, I was wondering if there is a better solution already.
I think, a lot of library developers will have the same problem. This still looks like a workaround for a very common problem.

Thanks for any comments.

[Alain Ekambi]

Using 2b and works perfectly :)

--
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-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.