The Google Webtoolkit

Developing web applications in Java for a couple of years now the big annoyance part always was the GUI part. Making it work in every browser, implementing AJAX, etc.. AJAX is hot nowadays and when demands are rising I started looking for an easy to use AJAX framework to build a web application GUI in. I came across many frameworks like YUI (Yahoo User Interfaces), DWR in combination with spring MVC, Wicket and many more. The one that stood out the most was GWT (Google Web Toolkit). The nice thing about this framework is that you only code in Java :-). No more HTML, Javascript etc.. But if you really want to use HTML and Javascript (In some specific cases) you can, so full flexibility is available.


How does it work than? Your package structure needs to have a package called ...client and ...server. All code that is written in the client application is compiled to javascripts and HTML files are created where needed. The javascript that is created is compliant to the most used browsers like:
IE, Firefox, Mozilla, Safari and Opera. So no need to focus on that part anymore ;-). It's also optimized already for you so it will work as fast as possible.


Since this framework/toolkit is component oriented and implemented very nice it's much easier to reuse components. You can actually reuse components by using JAR files :-). Another great thing is that you don't have to do a mind switch because you are still coding Java with type checking etc. So you know what you write actually works. Something that you don't have when coding javascript. As we all know it's very error prone and hard to write good quality javascript that will work in every browser. The learning curve is therefore not steep at all. Coding with GWT looks and feels like coding a regular Swing application. I think this is the real power of GWT. Creating GUI's like you are used to be doing. Even if you didn't develop in Java it's the same principal i.e. in VB, Delphi, Borland C++ etc.. It's all roughly the same unlike using Struts, JSF, Spring MVC etc. Those are frameworks using a different approach and have a steep learning curve. Actually I wonder why no one else came up with this kind of technology earlier. It would have saved us a lot of headaches. At least that is my experience. I didn't come across any other framework that is as easy as the GWT. A lot off people think it's wonderful but I think they didn't really take a good look at GWT. I used Wicket and GWT both and must say that GWT is much better implemented and saves you more time in development.


I must say that Wicket is much better than i.e. Struts or Spring MVC but it doesn't beat GWT. GWT has more capabilities. To make your application look good and have drag & drop etc.. you can use i.e. GWT-ext. This way you can use the Javascript Ext components in GWT without writing javascript! :-D It looks very nice: http://code.google.com/p/gwt-ext/
So on that part you also save a lot of time because this library has a lot of controls/widgets you can use out of the box like a sortable table, calendars and many more. GWT 1.5 will support Java 5 syntax so that will be no issue anymore for the people that use Java 5. It's already available but isn't released yet.


There are also some nice Eclipse plug-ins for GWT like the GWT Designer from instantiations. You can take a look at it here:
http://www.instantiations.com/gwtdesigner/index.html


I recommend this one. It doesn't cost much and saves you a lot of time creating a GUI. Just drag & drop your components on to the screen and voila!


So I would say invest some time in the GWT and I am sure you will like it ;-)

Comments

Post a Comment

Popular posts from this blog

Fastest XML parser

In most applications you need to do some XML parsing to either provide XML to external systems or parse XML from external systems or of course both. Since the systems I work on use a lot of XML and they need to be as fast as possible I did some tests on several XML parsers. I tested the following parsers/XML frameworks: JDom Piccolo StaxMate XStream JAXB 2.1 All parsers were tested in isolation with the following parameters: 25 threads running simultaniously Every thread calls the parser 100 times The results are as follows. JDom Avg. parsing time: 325.24 ms Avg. memory usage: 307 KB Piccolo Avg. parsing time: 88.08 ms Avg. memory usage: 454 KB StaxMate Avg. parsing time: 96.16 ms Avg. memory usage: 203 KB XStream Avg. parsing time: 77.04 ms Avg. memory usage: 319 KB Jaxb 2.1 Avg. parsing time: 1778.12 ms Avg. memory usage: 618 KB As you can see XStream is the fastest one of them all. The total ranking of the parsers you can find below: XStream Piccolo StaxMate JDom JAXB 2.1
Read more

Tomcat behind Apache HTTP server using Spring Security

Since I have been struggling with applications not working properly behind Apache HTTP server that use Spring Security I dedicated this blog to this issue. When you develop an application using Spring security this works fine when just running on a Tomcat server e.g. http://localhost:8080/app-context/. The problems start when you want to setup your environment properly by adding an Apache HTTP server in front of it using proxy AJP. You would start by adding the following to your apache config file: ProxyPass /app-context/ ajp://localhost:8009/app-context/ This works fine when trying to go to http://servername/app-context/ but when you try to login you will be redirected back to the login page everytime. To avoid this behavior you need to add the following line to your Apache configuration: ProxyPass /app-context/j_spring_security_check ajp://localhost:8009/app-context/j_spring_security_check For some reason it doesn't work without this line which seems weird to me since you basical
Read more

Cargo-itest open source project

I recently started an open source project called cargo-itest. This was started up because when I worked on several projects I needed to create integration tests for them which all had similarities. I was previously doing it with the maven2 cargo plug-in but wasn't really fond of it because it most of the times didn't work and when it worked it stopped working after editing the configuration. In other words it was very unstable. This initiated me to start to use the java API of Cargo instead of the maven plugin. By using the java API it already removes the dependency from your build system in this case Maven. Having no dependency on the build system gives you a couple of advantages: You can run it in any IDE that supports JUnit. You can switch easily to another build system without changing your tests and test configuration. These are general advantages of just using the API but also part of using my open source project cargo-itest. This project enables you to easily start creat
Read more