Google Web Toolkit is a set of libraries (aka. framework) that lets you create AJAX enabled web-sites without having to know any JavaScript or dealing with the inner workings of the protocol.
Basically you create your user interfaces in Java in a way that is similar to AWT or Swing, test, debug it using your java IDE of choice and when you are satisfied compile it to JavaScript to be deployed.
The resulting HTML/JavaScript/CSS files are cross-browser compatible.
If your application depends on server-side inteligence (lets say you access a DB) you will write 'services' (not the same as web-services, beware) in any language you like (just Java is featured on the samples, tough) and call then using GWT RPC calls.
The standard GWT services inherit from the traditional Servlets interface so they can be considered as Servlets, altough you don't generally use any of the Session objects that characterize a Servlet.
These services exchange information with the client in an assyncronous way. The UI call the server and continues working normally. When the answer arrives, it is displayed. That's AJAX.
Information goes to the service in the form of method parameters and returns to the client as a 'callback object'. Both method paramethers and the returned object are required to be 'serializabe' following GWT rules.
Errors come in the form of exceptions and should be taken care in the UI (you could just supress it on the server side, if you want to write bad SW). The standard RPC call should include the methods 'onSucess' where you use the received data and 'onFailure' where you do error treatment.
A big change from previous approaches is that Session state should be managed at client side, not server side. If you want you can still recover the session object and manage state the traditional way, people doesn't seen to be doing that tough. At the very basic, it will require server iterations that are not needed. With AJAX, the client is stateful and the server is stateless.
What came hard to me is how JSP and Servlets mix and match with GWT. The answer is: They don't need to. Altough you can pass information to and from JSP/Servlets via Session objects, you can build any user interface and client/server iteration needed for your application in GWT alone. Unless you need to add AJAX to some specific points in an pre-existing web application, not using JSP or Servlets at all seens to be the easiest way.
Java code used on the client side must be translatable to JavaScript and so is restricted to Java 1.4 specification for the packages java.lang and java.util. On the server side anything can be used, meaning any version of Java, or if you want to take the pain to handle the RPC calls, any programming language.
Styling of the application is done via CSS. The CSS file is defined in the 'module' that defines your GWT application.
Internationalization and Unit Tests (Junit) are easily implemented via the 'stub generating' scripts available. I18n is done via a proprierties file in which the variables representing the strings in your application are entered. You refer to these variables in your code and use the script to compile an interface (that you should implement) that will contain the corresponding strings.
Widgets are user interface objects (like an menu or a navigation tree) that can be used to build your application. GWT ships with a handfull of those that can be combined in 'composites' thus creating new widgets.
There are plenty of freely available composites/Widgets on the internet to implement common functionalities like drag and drop, calendars, color pickers.
Normally you will display the results of your RPC calls using some Widget.
How I created the basic GWT project for gPasma:
This allows the project to be easily imported in Eclipse
projectCreator -eclipse gPasma
Creates the basic folder layout and sample 'hello world' app
applicationCreator -eclipse gPasma com.haagahelia.client.GPasma
The gwt library (from where you run this scripts) must be inside the workspace in order to the 'run' functionality to work from inside Eclipse. I actually suggest the folder for the project is created manually and a folder /lib is added to it with GWT inside it before the scripts are run.
When you download the sources from CVS you will probably have to edit the path to GWT jar files in the following files:
Normal:
gPasma-compile.cmd
gPasmaConstants-i18n.cmd
gPasma-shell.cmd
gPasmaTest-hosted.cmd
gPasmaTest-web.cmd
If you are using Eclipse, then alter the [Path to GWT] and [Path to Proj] in the following files,
where applicable:
.classpath
gPasma.launch
gPasmaConstants-i18n.launch
gPasmaTest-hosted.launch
gPasmaTest.web.launch
The i18n and Test files are used by internationalization and Junit respectively and may not be available in the project yet.
Some references:
GWT site:
http://code.google.com/webtoolkit
Kick start guides:
http://google.wikia.com/wiki/Jump_Start_Your_AJAX_Development_with_the_Google_Web_Toolkit
Making RPC calls:
http://roberthanson.blogspot.com/2006/06/trivial-gwt-example.html
Deploying:
http://jroller.com/page/kenlars99?entry=deploying_the_gwt_dynatable_example
Wednesday, June 20, 2007
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment