Re: Updating GWT libraries for supporting xsiframe

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!

On Wednesday, January 2, 2013 6:21:41 PM UTC-2, Colin Alworth wrote:

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.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/QV3SzHaC5iQJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.