I recently took on some work that involved creating a web frontend to some configuration data on a server. The configuration information was in an XML file, and essentially consisted of a list of server directories and various pieces of information related to each directory.
The goal was to create some web frontend method of editing this XML file. Given that the configuration could list 100’s of directories, the solution I thought needed some tabular way of editing the data. The obvious idea I thought would be to use some AJAX solution. That would give a smooth user experience, and would generally ‘look good’.
jqGrid comes with some doco and quite a few examples. It didn’t take too long to hack together a simple setup that allowed me to edit cells and have the updates go to/from a server. However, the type of grid I really wanted to do was reasonably complex and really needed editable cells containing a composite of text boxes, dropdowns and other stuff.
I could see that my changes might be possible … but at the expense of modifying the jqGrid plugin itself to meet my needs. This approach never appeals to me. Both jQuery and jqGrid are still under some development, so my thoughts are always “What happens in a ‘years’ time when this thing needs bugs fixed or a modification made?”. Do you update jQuery and/or jqGrid and then consequently do you need to work out how to patch the more recent jqGrid to keep the thing working? I kept thinking there was probably a better solution (keep in mind that jqGrid and jQuery are rather good, but they didn’t suit my requirements here).
But it offers a lot more. To me it allows you to develop a client/server type setup entirely in java as though you were writing a regular local client app to run natively on say Windows (there are some limitations of course). There’s a GUI framework within it that allows you place widgets on screen and handle user interaction too. I guess it abstracts you away from ‘the browser’ and makes you think more in terms of purely client and server.
One of the cooler parts of it is that you can develop using an Eclipse plugin. So you write your code in Eclipse and then it has this thing called Hosted mode where basically you can debug the entire client and server using a built in servlet server (Jetty) and a browser. I assumed the debug cycle would be ; write some code, compile to java script, check the result in a browser …. and repeat. However, in this Hosted Mode it can (most of the time) pick up changes to your code dynamically, so the process becomes; write some code, click refresh in the hosted mode browser … and repeat.
If the server side of your code can run on a servlet server, you can develop it all as part of your project in eclipse and check it as you go. And GWT has its own remote procedure call stuff, so you can mostly abstract away the whole async http request stuff.
And lastly, one thing I like about most of Googles ‘offerings’ is that they bother to write decent doco and intro’s for there stuff. And I think they must get someone to proof read or make it sure it meets some standard. The GWT site has a decent Getting Started Tutorial and other documentation. And hey, you can even tell they updated the tutorial so that it relates to the current version of GWT (1.6.4 as I write this)
So I was excited by GWT, but I had a few problems;
- I don’t know Java.
- I don’t know GWT
- I don’t know Eclipse
So how could I not know Java? As a nerdy type approaching the big four oh, I spent my youth programming in procedural languages and ended up spending a lot of time writing in various assembly languages (6502, Z80, 68000) and then C. I never really caught onto the whole ‘Object Oriented Programming’ thing. I have a few books on Java and have tried to learn a few times in the past, but always lost interest. I am fine with the syntax of the language, but the whole OOP methodology generally baffles me. I am always left with the question of “Why do it this way?” … which most java books seem to avoid the answer to. So by using GWT I’ve kind of forced myself to relearn Java (often a good project is all it takes to learn a new language). My thoughts now are “It’s not too awful”. As a language I kind of think it lets you write really sad looking code, and yet your app doesn’t crash. I guess that helps answer my ‘Why?’ question. I’m still pretty vague on all the various OOP principles though.
GWT is effectively the base of Java plus its own frameworks. There’s a lot of them. It takes some time to get around it all, and to see how everything works together. In the case of my app, the GUI side of things is relatively straightforward but there’s also a lot of XML involved and for whatever reasons I decided to send stuff to and from the server in XML … which meant trying to understand how GWT works with XML.
Previously, my preconception of Eclipse was that it was a fancy text editor written in Java designed to eat all your RAM and CPU resources. Of course, now that I’ve installed it and used it I can see that it is rather handy, especially all the predictive/hinting stuff it does and the sheer power of its plugin architecture. The big downside is that the user interface is incredibly ‘busy’. The main IDE I’ve been using before this was Xcode … and its very uncluttered in comparison. I can kind of navigate and do what I want in it now, but initially I found it quite hard. It has a lot of ‘metaphors’ I just wasn’t used to. I even had trouble initially just trying to import some of the GWT sample projects. I still think it’s a resource hog (so it helps to have a decent spec machine), but I must admit that it probably does improve productivity. As a side note, I’ve been running all this GWT stuff on my Macbook (running Leopard). It was pretty easy to set up. However, I also tried to get it running on my Ubuntu Jaunty (9.04) 64 bit linux server. I ended up giving up. Essentially GWT is 32bit as far as I could tell, and even though I think it’s possible to get it running on 64bit linux, it looked very very painful.