Unlike other Java to JavaScript frameworks (jMaki for example) that require actually to be hosted in a Java VM container, GWT produces the client side JavaScript code as a final product. So Java, in this case, is just a tool, not part of the end result. Of course, if there is server in the backend to handle the RPC calls,  Java Servlets can be used to facilitate that, but it is not mandatory.

GWT is not just a tool for Java developers who don’t like coding JavaScript. It also put AJAX into better perspective by separating the client and service code in the code base. Using JSON as the messaging protocol between the client and server, a GWT client application can talk to any web server that speaks the language, which doesn’t have to be implemented in Java. GWT also provides a way to work around SOP – the Same Origin Policy.

SOP is the security policy that is in the web browser to stop a client script to communicate with web server that the script is not originally from, in another word, any arbitrary web server. This is a necessary security measurement, but it makes the client less distributive. For example, a web service provider would like to distribute a small version of client script, which can be embedded in any web sites, and get the dynamic information from the service host. GWT handles this by requiring server to return JSON output in a “<script>” tag, and a callback function will also need to be defined to handle the output.

With the advance of web technology, JavaScript will play much bigger part in rich web applications in the future. I think the biggest strength of GWT is its capability to scale up the size of a JavaScript project. Following the Java’s footprint a project created using GWT can be better managed, tested and collaborated among developers.

One drawback is that one has to be familiar with Java. And obviously there is a little bit of learning curve on those GWT GUI APIs. Nonetheless it is a great tool for Java developer to natually adopt and use to create some great JavaScript applications.

var myUndefinedVar = 1;

if (myUndefinedVar) {

// do some stuff

}

Even the browser will throw out an Javascript error, the code works since there is no else statement or other intended logics beneath the if block in this case. Otherwise, we won’t be so lucky since the browser will stop executing the rest of the statements. A better way is using the typeof operator, which will not result in an browser error even the variable is undefined. Here is a code example:

if (typeof(myUndefinedVar) == ‘undefined’) {

// do this

} else {

// do that

}

Notice that, the following code will work whether the document element is there or not.

if (document.getElementById(’blah’)) {

}

The reason is that document is always a valid object and getElementById will either return an object or a null value, which in either case, will not cause the browser to throw up.

However there is some limitation to use Ajax to post a multi-part form. Although it might be possible, it is definitely not a clean implementation, and it is not supported by most of the browsers. In this case, iFrame may be a good alternative. The inner frame page will handle the multi-part form and the parent page will have the similar Ajax effect. That being said, iFrame’s biggest problem is that its width and height are set right from the start and it won’t adjust based on the source content. This will leave the ugly scrolling bars around the iFrame, or some content will be hidden if the scroll bar is disabled. For most of the pages, the width is somewhat less of a problem but the height is harder to control and set correctly.

The good news is there are ways to dynamically adjust the height of the iFrame based on the inner content. There are different ways to achieve this using JavaScript. I found this approach is the best:

Using jQuery, we can add the following code in the iframe source content:

<script type=”text/javascript”>
$(document).ready(function() {
var theFrame = $(”#iFrameToAdjust”, parent.document.body);
theFrame.height($(document.body).height() + 30);
});
</script>

The JavaScript will get the iframe object from the parent DOM and change its height according to the size of the current document after the document is loaded (very important to get the true size). I like it because it is less intrusive to the page where the iframe is on, and the iframe source kind of “take care of its own size” when being displayed. If the source page is displayed as regular page, there simply will not be any adjustment. With the help of jQuery the code is quite clean and simple. Of course the iframe source has to be an internal page and the developer has the permission to add the code.

From my testing result, this works in FF2, IE7 and Opera 9.25, not in Safari 3.1 for Windows though.

Some updates:

I found it work better to put the JavaScript which adjusts the frame height in the body onLoad attribute. Basically “ready” function will be kicked off when the DOM is loaded, at which point the page may or may not be completely loaded. The onLoad event will be a better bet in this case since we need the actual size of the page including all the images.

We can use a javascript to implement this.

/** checkChange.js **/ 

var alertLeavingPage = false; /* flag to turn on the alert */
var pageInputChanged = false; /* the flag of changes made */

// The onbeforeonload is called before the page is changed. It is not a standard
// method. But it is supported by IE and FF.
window.onbeforeunload = function(theEvent) {
   if (pageInputChanged == true && alertLeavingPage == true) {
      if (typeof theEvent == 'undefined') {
         theEvent = window.event;
      }
      if (theEvent) {
         theEvent.returnValue = "You have made some changes on this page, please click OK to discard the changes or Cancel to stay on the page.";
      }
   } else {
      return;
   }
}

/*
 * The method should be called on the page where the change needs to be tracked.
 * The form ID needs to be provided so the change event can be registered on certain form elements.
 */
function trackChange(formId) {
   var formElem = document.getElementById(formId);
   if (formElem) {
      for (var i=0; i<formElem.elements.length; i++) {
         var inputElem = formElem.elements[i];
         if (inputElem.type) {
            var inputType = inputElem.type.toLowerCase();
            if (inputType == 'text' || inputType == 'radio' ||
                inputType == 'checkbox' || inputType == 'select-one' || inputType == 'textarea') {
               inputElem.onchange = setChangedFlag;
            }
         }
      }
      // turn on the alert flag
      alertLeavingPage = true;
   }
}

/*
 * The method which is tied to a change event.
 */
function setChangedFlag(evt) {
   pageInputChanged = true;
}

Of course you will need to include this script to the web page. Besides that, you also need to call the trackChange() method to register the form elements that we want to track. So a form Id needs to be set in order to register. A sample html page look like following: 

<html>

<form id="the_form_id" action="" onsubmit="alertLeavingPage=false; /* no reminder for submission */"> 

</form> 

<script type="text/javascript">
<!– //
trackChange('the_form_id');

// –></script>

</html> 

Once they are added into the page, the user should see this prompt when they leave the page with un-submitted inputs. 

The method only detects whether there has been any change activity and it won't be able to tell whether there is change being made. For example, if someone checks a checkbox and unchecks it the script will think there has been change made.