We had a kind of niche case client requirement recently. The client has two (very) separate web applications deployed on their network. One a regular web app, the other a GWT based IM client. The interesting requirement was having the two applications integrate with each other on the client, essentially launch the GWT based app from the regular web-app.
The first issue was exposing enough of the GWT API to native javascript. Not too much of a problem, after a bit of googling (still the developers best friend) use of the Java Script Native Interface (JSNI) looked to be the best bet. The code looks like this –
public native void exposeCreateAction() /*-{
var that = this;
$wnd.createAction = $entry(function(parameter) {
that.@mypackage.MyEntryPoint::executeCreateAction(Ljava/lang/String;)(parameter)
});
}-*/
Ok, so that’s pretty terse, and there are a couple of things that need pointed out. ‘that = this’ – when the JSNI actually gets executed ‘this’ is out of scope, so we add a closure around ‘this’ hence the need for ‘that’. The $entry function is an implicitly defined function which installs an exception handler for Java derived methods, and the advice is that it should be used anywhere GWT-derived javascipt is called from a non-GWT context. There’s a single String parameter expected.
A bit of testing in Chrome’s developer tools and that appears to be working as expected. The above code is put in the onModuleLoad() method in the GWT entry point to ensure that its been executed.
Okay, so that’s fine and works. This is where a couple of bumps were happened on and need to be ironed out. The clients requirement is to launch the GWT app in a new window on a user driven event, unless the window is already opened in which the current window should be re-used. So, the event handler in the parent app needs to do a couple of things
i) Decide whether or not a window for the GWT app has already been launched.
ii) Call the JSNI exposed function
iii) Give focus to the GWT app.
i) is relatively straightforward. Use a variable to hold the reference to the window returned from the ‘window.open()’ function, we can check if the variable is defined, the closed property on the window and finally the location that the window is currently referencing. The later there is just in case the GWT app has already been created but the user has since navigated away.
ii) was trickier than it looked, should be easy huh?
gwtAppWindow.createAction("myParameter");
Nope. There’s a timing problem if this is the first time the GWT app is being launched so the ‘createAction’ won’t be defined yet. The method used to get round that was to set-up a callback from the EntryPoint to notify the host page when that the GWT app has loaded.
Scheduler.get().scheduleDeferred(new ScheduledCommand() {
@Override
public void execute() {
notifyHostPage();
}
});
where notifyHostPage() looks like –
private native void notifyHostPage() /*-{
// Only make the call to the onGwtReady method if it has been setup.
if (typeof $wnd.onGwtReady != 'undefined') {
$wnd.onGwtReady();
}
}-*/;
iii) only needs some code to navigate around Firefox’s decision to ignore the ‘focus’ call.
The final hurdle to overcome was the browsers Same Origin Policy (SOP). The preferred solution is to use the ‘document.domain’ variable to set the domain of the page to a subset of the actual domain. What happens then is that subsequent same origin checks are passed. Here’s the scenario, in the host app the domain is ‘webapp.mycompany.com’ and the domain for the GWT app is ‘gwtapp.mycompany.com’, in both the apps set ‘document.domain’ to ‘mycompany.com’. Finally. Job done, but its nasty.
