Comment by a.revolution.ultra.blue:
One hack I was using to get modules to "speak through compilations" was
using Ray's exporter. Basically, common functions like custom dialogs that
cover the screen... If I want them to look nice, but be accessible before
I ever access Widget code, I use public static class methods like
note(String txt), ask(String question, AsyncCallback response, String ...
answers). These methods aren't even in the same package as the code that
implements them; they just tunnel through a "JS API"
$wnd.parent.MyExportedAPI. The root API module puts a JS object
MyExportedAPI on it's $wnd, then it loads the "dll" nocache.js files, which
implement things like note() and ask(), adding them to
MyExportedAPI.Dialog.ask()
Finally, each osgi iframe has .nocache.js modules that never access the
packages which implement the UI stuff, only static methods that tunnel to
$wnd.parent.ME_API {or $wnd.parent.parent...ME_API}. Biggest issue was
context. All callbacks from an osgi child of the root must send along it's
window variables {NOT $wnd}, and map all the parameters in and out of JSNI.
Think:
public static native void getFeeling(AsyncCallback<String> callback)
/*-{
top.MyExportedAPI.ask("How are you", ["Good","Great","Alright"], {
wind: window
, callback : callba...@com...asynccallback::onSuccess(Ljava/lang/String;)
, err : callba...@com...asynccallback::onFailure(Ljava/lang/Throwable;)
});
}-*/;
then, to actually perform the callback, in JSNI,
x.callback.call(x.wind, 'Great')
PROBLEMS {only some of them}:
* Memory leaks; adding gwt workspace iframe.contentWindow to every tunneled
call could get REAL messy.
* Hand coded; it works, but there's piles and piles of boilerplate code;
external public static access, a to JSNI bridge method, a from JSNI bridge,
and finally, an implementation method. Don't forget @Export boilerplate
too!
* Tracing errors becomes nearly impossible. Had to make a special,
ForeignException so different frames could throw an error and call an
asyncCallback.onFailure without ClassCastException.
* Accessing osgi subframes {/ls, /dl} without being a child of the root
frame = not possible. Power users like to skip straight to the url w/
content, sans fancy multiple-module downloads.
* "Dlls" came in .cache.html, so they didn't block downloads of other code,
which I thought was an advantage, but with heavy caching situations, weird
page reload bugs happened when the root api changed, but the children did
not.
* Proxied calls were slllllow
* Event.addNativeEventListener does not work through iframes
* Compile times through the roof!!
* A giant wad of atrocities I've tried to block out.
Trust me, the amount of extra dancing and working you will have to do
for "dll osgi-like modules" will cost you more time than money can
replace. And what Ray mentioned before about RPC is that your obfuscated
Java objects CANNOT sanely be made translatable unless you RPC
encode/decode when tunneling to the root MyExportedAPI. This would mean an
encode/decode pair of overhead methods for every paramete or returned
object that's not a primitive or JSO.
I did all this before runAsync and GWT2.0 was compatible with Appengine,
and I TOTALLY ABANDONDED THIS METHOD. It hurt too much to implement.
Maybe if I was a generator wizard like Ray it wouldn't be so bad, but at
least my package segregation methods made the "root API" modules
transferable to runAsync without worry of external dependancy.
...If you feel like you wasted time reading these run on sentences of mine,
do yourself a favor, AND SPARE YOUR CODING TIME, COMPILING TIME AND
EXECUTION SPEED: *Monolithic* *Compile* *Is* *The* *Only* _efficient_
*Way* *To* *Obfuscate*, *Split* *And* *Link* *Independent* *Modules*. Any
other way means a translation layer and jumping through lots of unnecessary
hoops!
For more information:
http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
