All posts by moore - 81. page

This past week has been a whirlwind, including a whole lot of learning on my part and three releases of the Colorado HomeFinder site. Just to rehash, I’ve built three versions of the software:

• A standalone javascript version. A toy which introduced me to GWT (src)
• A calculator that pulled some data from an external expresso server. (src)
• And finally, a more complicated version of the calculator, which also included a servlet so everything would run fine in hosted mode. (src)

In general, from a java developer perspective, this is my take on the strengths and weaknesses of GWT.

Strengths:

• Can use normal java dev/debug environment–in particular, being able to set breakpoints in what will be javascript was useful
• Hides javascript cross browser messiness
• Allows rich uis to be built for web using same paradigms as other windowing toolkits (event listeners, layouts, panels, etc). As some folks have said, it is Swing for the web.
• Ability to create widget libraries–using module ‘inheritance’ you can easily leverage other folk’s work. See this list for a collection of GWT widgets.

Weaknesses:

• Build integration–I really don’t understand why they haven’t wrapped in an ant task, though others have done it for them, and there is an -ant switch on projectCreator.cmd which generates a stub build.xml
• Documentation–again, I’ve found the Google Groups to be tremendous, while the Google provided documentation could use some brushing up.
• Some cross browser weirdnesses–the only serious one I saw was IE not responding to click events on one page I built. This was due to a table of width 100% next to the div where the GWT widgets were dynamically creating DOM elements. But it only showed up on IE.
• Any ui built by GWT is not indexable by search engines. This necessarily limits what you can do with it–you can build web applications but not web sites.

Previously, I described how to integrate a network call into the GWT mortgage calculator. (See Step #2, Step #2a and Step #2b.) Now I’m going to add an another, more complex mortgage calculator panel. This will add in more real world costs. Both the simple and advanced calculators will be available at the same time, using a tabbed interface. Additionally, I’ve added a servlet which will serve up correct JSON in hosted mode, which means that anyone who wants to download and play with this code will be able to do so without any software beyond the source, the GWT, and a modern version of Eclipse. See the new tabbed interface in action and download the source. (Please note that the interface online is not exactly the same as the interface you can build via the download–my client had me make a couple of changes.) I’ll also talk about how I integrated this calculator onto a property specific page.

Adding a tabbed interface was actually quite easy. I used a TabPanel. The only hiccup was that you cannot reuse widgets. I thought it’d be nice if the loan amount, for example, stayed the same between the tabs. However, if you place a widget in two different containers, the last one wins–the widget simply isn’t in the first container. I tested this with the VerticalPanel and the FlexTable. Instead, I had to create new widgets. I’m sure that I could have achieved synchronicity between widgets with a KeyboardListener, but the payoff didn’t seem worth the hassle. Other than that, this is a minor revision. I did some refactoring and pushed validation up to the button widgets.

The JSONServlet shows how to keep server and client source in the same tree, and also provides a simple way to toy with JSON client-server communication. I tested this and you should be able to simply untar the source, import the project into Eclipse, do a bit of GWT judo, and run the project. Steps (only tested for windows, sorry) to reproduce the final working product:

• You will have to download the GWT since I can’t legally redistribute it.
• Unzip it into, for example, c:\gwt
• Download and untar the mortgage calculator source, say into c:\mtgcalc
• Copy gwt-user.jar and gwt-dev-windows.jar into the lib directory, for example c:\mtgcalc\lib. (This lets you run the MortgageCalc-compile.cmd batch file to compile the app from the command line. If you just want to see the javascript in action, you can stop there and copy the resulting .html/.xml/.gif files to a host someplace and view in a browser.)
• To set up the debugging, start Eclipse.
• Import the project vai the File \ Import menu item.
• When you’re ready to run the browser in hosted mode, edit the launcher in Eclipse. Choose the Run menu, then the Run… option.
• Select the MortgageCalc application (under Java Application)
• Choose the Classpath tab. Remove the gwt-user.jar and gwt-dev-windows.jar files.
• Click under ‘User Entries’
• Click the ‘Add External Jars’ button.
• Navigate to where you unzipped GWT (for example, c:\gwt and select both gwt-user.jar and gwt-dev-windows.jar
• Click ‘Open’
• You should see the two jars with this icon next to them: . If you see this one instead: , that means you added them as jars, not as external jars, and you won’t be able to run in hosted mode. (Updated 6/21: You’ll get the error described here: [ERROR] The browser widget class could not be instantiated java.lang.UnsatisfiedLinkError: Unable to load required native library 'gwt-ll')
• Click ‘Apply’ and then ‘Run’.

The next step is to integrate the calculator into an existing JSP and pull some information from that JSP page. Since this is tightly integrated into the Colorado HomeFinder site, code would probably not be useful, so it’s not provided. However, if you’d like to see the results, visit Colorado HomeFinder and search for a home, click through to a property and then click the ‘Mortgage Payment’ link. (Sorry this process is not streamlined, but any link I put to a specific property page on that site will expire in a few months.)

The ideal calculator gets listing price and other information from the server, and prepopulates the appropriate fields. However, the calculator needs to know what property it is being shown for; in other words, it needs to pick property specific data out of the page. There are a couple of possible methods: I could write a javascript variable to the page and use JSNI to turn it into a data structure that my compiled gwt code could read. Or I could put text into a hidden div and then use the Google DOM classes to get the data.

Since what I needed to retrieve was a few simple numeric values, I went with the DOM option. If I had a more complex data structure to communicate, using JSNI might have been a better option. I used getElementById to find the appropriate div and getInnerText to get the contents of that division. With those pieces, I could query back to the server and get the price, taxes, etc. which I would use to fill in the appropriate text boxes on the mortgage calculator.

And I believe that’s all for now. There are, of course, many places where Icould expand this calculator, but this is functional enough and we now have an understanding of the strengths and weaknesses of GWT. And that’s the subject of my next post.

The next step is to update the client to communicate with the server side components. Again, if you’re not very patient, you can see the live client code at Colorado HomeFinder, and download the source.

I need to add a drop down, which will offer users the option of a 5/25 ARM rate, or a 30 year fixed rate. I need to have some way of decoding the JSON response from the server, and I need to update the interest rate text box with the results from the server.

Adding the drop down is fairly easy: Google provides a listbox. The listbox is an instance variable, rather than a local variable, and I also change the interest text box from a local variable to an instance variable. The reason: the change listener, which is a non static member class, has easier access to an instance variable than to a local one. Here’s the relevant code:

rateChoiceBox.addItem("5/25 ARM");
rateChoiceBox.addItem("30 Year Fixed");
rateChoiceBox.setVisibleItemCount(1);
rateChoiceBox.setWidth(width);
final RatesResponseHandler rrh = new RatesResponseHandler();
HTTPRequest.asyncGet(RATES_URL, rrh);

rateChoiceBox.addChangeListener(new ChangeListener(){
public void onChange(Widget sender) {
HTTPRequest.asyncGet(RATES_URL, rrh);
}
}
);
...
private class RatesResponseHandler implements ResponseTextHandler {

public void onCompletion(String responseText) {
boolean keepGoing = true;
JSONObject jso = null;
try {
jso = JSONParser.parse(responseText);
} catch (JSONException je) {
keepGoing = false;
// not sure what to do
}
String rate = "";
// ... get the data, put it into the rate variable.
MortgageCalc.this.interest.setText(rate);
}
}

In the RatesResponseHandler, I try to parse the JSON response that has been asynchronously downloaded from the server, and if I get meaningful text, I set the interest rate in the textbox: MortgageCalc.this.interest.setText(rate); If the server is not available, we still have a sane default. One interesting item: when you run the code with the server off in development, GWT pops you into the MS script debugger, which at least lets you know something is wrong.

The JSON processing code has already been written, so it made sense to leverage the JSON example that Google kindly provided. To do this, I made a few changes. Luckily, all the example code is made available under the Apache 2.0 license. You can find json.jar in the download, should you want to use it for a project of your own.

First, I wanted to make sure that none of the behavior of the EntryPoint JSON class occurred–I wanted the subsidiary libraries, but not the potato demostration. Therefore, I eviscerated the JSON class, and gave it an empty onModuleLoad method. On reading the module documentation, it appears this wasn’t needed–I could have just eliminated the <entry-point> entry.

Then, I started building the JSON code library. To pull in a set of external widgets, you need to do a couple of things.

1. Build the library. I did this by compiling the JSON source, from the samples directory: mkdir builddir && javac -d builddir -classpath `cygpath -wp $PWD/bin/:.:../../../gwt-windows-1.0.21/gwt-user.jar` src/com/google/gwt/sample/json/client/JSON*.java. (The cygpath stuff is there because I’m developing on cygwin.) One thing to remember–you need to copy the java files into that same build directory: cd builddir/com/google/gwt/sample/json/client && cp ../../../../../../src/com/google/gwt/sample/json/client/*.java .. (Apparently you need the .class files for Eclipse or any other IDE, and you need to .java files so the Google compiler can compile the java to javascript. More here.) Also, don’t forget the JSON.gwt.xml, which should go in builddir/com/google/gwt/sample/json.
2. Jar up the code, and place it in the classpaths. To compile from the command line, I added it to the Mortgage-compile.cmd batch file. For Eclipse development, I added it to the project buildpath (instructions for doing so). And I also had to add the json.jar file to the MortgageCalc application, so I could debug in Eclipse. To do this, choose ‘Run’ from the top menu, choose the ‘Run…’ option, select ‘MortgageCalc’, click the ‘Classpath’ tab, click ‘User Entries’ and add the jar using the Add button.
3. Inherit from the JSON module. As far as I can tell, this isn’t inheritance in the usual object oriented sense, it’s more like importing packages in java. I did this by adding this line to the MortgageCalc.gwt.xml: <inherits name='com.google.gwt.sample.json.JSON'/> (I did try to use a source path to refer to the JSON classes, rather than inherit from them, but got this error:
   

   [WARN] Non-canonical source package: ../../../google/gwt/sample/json/client/
   …
   [ERROR] Unable to find type ‘com.cohomefinder.gwt.mortgagecalculator.client.MortgageCalc’
   Hint: Check the inheritance chain from your module; it may not be inheriting a required module or a module may not be adding its source path entries properly

   )

After going through those steps, I could use the JSONParser and other JSON objects in my widget. Here’s the balance of the RateResponseHandler:

if (keepGoing && jso != null) {
int selected = MortgageCalc.this.rateChoiceBox.getSelectedIndex();
String [] keys = jso.getKeys();
if (keys.length == 2) { // expected
JSONValue jsvrate =
jso.get(keys[selected]);
JSONString jsstr = null;
if ((jsstr = jsvrate.isString()) != null) {
String rate = "";
if ((rate = jsstr.toString()) !=
null) {
//Window.alert("rate:
//"+rate);
MortgageCalc.this.interest.setText(rate);

}
}
}
}

The JSON parsing code is rather verbose. I also wasn’t a fan of the return values from the is* methods; I was always told that any method prefixed with ‘is’ should return a boolean. But then I peeked into the JSONParser class and decided that I’d just use the free code
and stop complaining. Final comments:

• The module inheritance system is a quite powerful, if slightly
  misnamed, method of reusing code. In fact, there is already at least one blog about GWT widgets.
• Packaging up code for a module is tedious, and perfectly suited to an
  ant task.
• HTTPRequest is entirely adequate for pulling down data.
• JSON, combined with HTTPRequest, gives you some typing, without tying
  you into a custom servlet. If you want typing stricter or more granular
  than javascript
  provides and are using a java backend, then Google’s
  services might be a better choice.

After choosing the means for transmitting the data, the next step is to build the server side code. For Expresso, that means creating a new controller and a new state. A controller is similar to a Struts action; one controller may have many states. Please be aware that if you want to play with the new client code, you can use almost any dynamic web aware language, or even a static HTML page, to return the appropriate JSON, which will look similar to this: {"fivearm":"5.00","thirtyfixed":"6.50"}.

Adding a new state to handle a request for mortgage interest data in Expresso is not too complicated, though it could definitely be easier. I needed to:

1. Add the values to the database. Expresso has a setup table for generic configuration information that I’ll use.
2. Create a class that extends DBController, and have this class access the database and create the JSON.
3. Update the configuration file to map a URL to a class. This version of Expresso is based on Struts.
4. Add a JSP for output.
5. Update the security tables so that this state can be accessed by everyone.

Adding the values to the database is just an insert statement. For the thirty year fixed interest rate, the SQL looks like this: insert into SETUP values ('com.cohomefinder.CoHomeFinderSchema', 'MTG_30_Year_Fixed_Rate','30 Year Fixed Mortgage Interest Rate','6.50');. One of the benefits of using the setup table is that Expresso ships with an Administrative Web Interface which lets non technical users change ‘setup values’ with a browser.

The next step is to create a class to respond to our request. That class is the MortgageCalculator controller. This is a fairly simple class, which uses the JSON.simple Java library to create a correctly formatted JSON object. Note that the rates are sent back as Strings even though JSON can handle converting to numbers. The reason for this is that I wanted some kind of formatting control; if the class sent back ‘6.5’ for the thirty year fixed interest rate, I might want it formatted as ‘6.50’. Formatting is simpler on the server, where I have the entire Java API to use, including NumberFormatter.

After that, I needed to create an entry in the configuration file to map some URL to this class.

<action path=”/MtgCalc” type=”com.cohomefinder.controller.MortgageCalculator” name=”default” scope=”request” validate=”false”>
<forward name=”getRatesAsJSON” path=”/expresso/components/registration/jsp/register/mtgcalc.jsp”/>
</action>

As you can see, this is very similar to configuring a struts-config.xml entry.

The JSP was extremely simple. It imports the expresso tag libraries in the standard manner, and then write the property that the MortgageCalculator class puts in the response (on the last line of the Java file).

<expresso:IfElementExists name=”JSON” type=”Output”><bean:write property=”JSON”/></expresso:IfElementExists>

The last thing to do is update the controller table to allow anyone to access this class. Again, it’s a simple SQL statement: insert into controllersecurity values ('com.cohomefinder.controller.MortgageCalculator','Everybody','*');. If I wanted to, I could restrict this information to certain classes of users, but in this case, everyone should have access to it.

After these steps, I can hit http://localhost:8080/MtgCalc.do?state=getRatesAsJSON and get back valid JSON containing values stored in the database.

The next step is to update the client to access the server data using HTTPRequest and to change the GUI accordingly.