/home/nick

Trying both GWT-Ext and Ext-GWT

In trying to make a decision on whether to go GWT-Ext or Ext-GWT I’ve done some reading including the websites of those two technologies, forums, and various blogs like:

http://www.gwtsite.com/top-5-gwt-libraries/
http://roberthanson.blogspot.com/2008/04/gwt-ext-vs-ext-gwt.html
http://ajaxian.com/archives/to-gwt-ext-or-to-ext-gwt

The most talked about topic when discussing this comparison seems to be licensing, but I don’t want to spend much time on that.  Instead of comparing the two technologies line by line, I take a small existing vanilla GWT application and add new needed functionality such as drag and drop, resizable columns, sortable columns, and additional layouts.  This was done first using GWT-Ext and then again using Ext-GWT.  The opinions I gather are based on coding with both over a few days.

GWT-Ext Experience

This was actually my second choice, and became my first choice based on comparing the licenses of the two.  My first steps were changing out widgets used and hoping that the underlying code dealing with the model wouldn’t need to be modified (much).  Layouts are one thing I noticed that are considerably different.  Instead of using VerticalPanel or HorizontalPanel, you use a Panel and add a modifier to make it flow vertical or horizontal, much like Swing.  While this is good if you know Swing, and are starting the app from scratch, it can be a pain if converting like i am.

Another difference when dealing with going vanilla GWT to GWT-Ext was rewriting code that handles FlexTable or GridPanel updates or, in other words, the way you get data into the table.  In GWT land, you can treat the FlexTable as the data, much like a two-dim array, and set data to the cells.  GWT-Ext uses something called a Store, which is basically the data itself.  When you add to the Store, the GridPanel gets updated.  There are pros and cons to both methods I suppose, but that’s another discussion.  I will say the reason I stopped using GWT-Ext was because of problems rendering the grid to the screen when using the GridPanel with certain layouts.  I suspected this was due to it being a js wrapper.  It turned out there was a known bug which required a workaround just to get the grid to show.  After spending many hours dealing with this problem and a few others I decided I shouldn’t be wasting my time with something that has problems taking one panel and adding it to another like panel.add(grid).  In GUI building, an operation like that is simple and frequent.

On to Ext-GWT

Last thing I wanted to do was revert back and start again, but here it goes.

One big difference between the two Exts is that GWT-Ext is just javascript wrapper.  It’s visible while configuring because you’ll add scripts and javascript libraries to your public folder.  With Ext-GWT none of that needed to be done.  This is because Ext-GWT is a GWT library and doesn’t wrap javascript.  I like this.

So I start again changing out widgets, and notice that there’s almost no work to be done.  The new widgets use same function calls as old ones.  They did drop the ball on the Button class and it’s listener (actually, I don’t like the way events are coded).  Not sure why you would not stick with a ClickListener and onClick()….but whatever.   The layouts are similar, and they include VerticalPanel as well.  Changing the FlexTable out for the Grid took some work, but less than GWT-Ext.  It does use a StoreList (similar to GWT-Ext’s Store) but I felt it made a little more sense.  There was little time spent correcting column sizes and dealing with autofills, which makes me happy, and there were no issues getting the Grid to show up.

Final Decision

Well, everything was fine but another day has passed and I’m just not 100% happy with Ext-GWT.  Running the hosted browser and compiling has become slower than ever (still faster than GWT-Ext though).  I got to thinking and realized that the only enhanced component I really needed was the Grid over the FlexTable, and I did get the grid setup just like I wanted.  Since one of the things I really hated about Ext-GWT was the event handling code, I asked myself: Do I really need to have all of my buttons, checkboxes, panels, etc in Ext-GWT?  Can’t I just use the fancy Grid and then make everything else using vanilla GWT?  I decided to try this, and not only did it work perfectly, but there was noticably lower load times and increased speed.

My final take is, use vanilla GWT for events and where you can use it.  For GWT components that are missing features you need use Ext-GWT.

I’m using this post to experiment with syntax highlighting in my blog.  Recently a friend needed a program to echo data on a socket while he was testing an internet appliance and some other network enabled hardware so I figured I’d just use that code as my example.

The EchoServer will open a listen socket on port 4444.  Compile it, run it and then to test it you can open a command prompt and type telnet localhost 4444

import java.io.InputStream;
import java.io.OutputStream;
import java.net.ServerSocket;
import java.net.Socket;
 
/**
 * @author NickC
 */
public class EchoServer {
   private static final int BUFFER_SIZE = 256; 
   private static int listenPort = 4444;
 
   public static void main(String[] args) throws Exception{
      ServerSocket serverSock = new ServerSocket(listenPort);
      System.out.println("listening on port "+listenPort);
      Socket sock = serverSock.accept();
      System.out.println("new connection " + sock);
 
      InputStream sockIn = sock.getInputStream();
      OutputStream sockOut = sock.getOutputStream();
      byte[] buffer = new byte[BUFFER_SIZE];
      while(true) {
         Thread.sleep(50);
         int count = 0;
         if ((count = sockIn.available()) > 0) {
            if (count >= buffer.length) {
               count = buffer.length;
            }
            count =  sockIn.read(buffer, 0, count);
            System.out.println("echoing "+count+" bytes");
            sockOut.write(buffer, 0, count);
            sockOut.flush();
         }
      }
   }
}

Source in a file: EchoServer.java

A short rundown on adding external directories to your Apache Tomcat webapp path.

I started with a simple problem and it turns out there’s a simple solution.

My problem:
In the current application I’m coding I display user data (like many apps).  Included with the user data, the page also shows the user’s photo.  The problem was that the photos were stored in a directory external to Tomcat (D:\photos) and I need to get my webapp access to that directory and have those photos in Tomcat’s path.

My Solution:
To solve this I needed to add what Apache calls a context path which can be done by adding an xml file.

Here’s a bit of given information so this is easier to follow.

• I’m using Tomcat 5.5
• The name of my webapp is called MyProject which is located at $CATALINA_HOME/webapps/MyProject
• The directory I’m trying to add to Tomcat’s path is “D:\photos“
• I want my photos to be accessible in the path $CATALINA_HOME/webapps/MyProject/photos (or http://localhost:8080/MyProject/photos).

Creating the context file:

• In $CATALINA_HOME/conf/[enginename]/[hostname]/ (in my case $CATALINA_HOME/conf/Catalina/localhost/) create a file called “MyProject#photos.xml“.  The value before the # is your webapp name and the value after is the path you want added.
• In this file add: <Context docBase=”d:\photos” /> and save.
• Restart Tomcat.

Note for GWT:  I can’t seem to get this working with the embedded Tomcat that comes with GWT.  If anyone knows a simply way, please let me know.  In the mean time I’m using full Tomcat with the noserver option, and for the name of my context file I’m putting the full package name.  For example: com.nick.MyProject#photos.xml