I'm sure by now there are plenty of blog entries out there... but I did
say awhile ago that I would share my experience with GWT.
I had been needing to put together a small application for my personal
use. I used GWT for the front end.
My summary of the experience:
GWT has, for the most part, good documentation, with occasional holes.
Setup is relatively painless
Watch out when running in hosted mode from eclipse because both the
"src" and the "bin" directories are required to be on the classpath
(this can lead to resources not being found due to multiple copies
existing in the classpath)
Creation of a very dynamic and responsive gui is fairly trivial,
especially if you're already familiar with swing, awt, and/or swt. You
can implement click listeners, mouse listeners, etc. to handle events.
The bundled components are really very nice. Tables, lists, trees,
"deck" panels (like a decklayout in swing), dockpanels (think
borderlayout in swing), grids, "flexible" tables that grow on demand as
you add more data, menus and more. Very nice. Pretty much all
styling/visuals can be controlled via css, which is also nice.
They've got everything setup for you (GWT comes with a (modified) tomcat
binary, even) so when you run in hosted mode, you get code hot-swapping,
full debugability, etc.
The built-in rpc mechanism is a nice abstraction over the
XMLHttpRequest. They take care of serialization, deserialization, etc.
But... if you're not used to thinking asynchronously when retrieving
data, performing operations, etc., it will take a bit of getting used
to. So, on the client, all calls look something like:
service.doCall(some,data,new AsyncCallback() { public void
OnSuccess(Object) { } public void onFailure(Object) {}};
The client-side code /only/ understands user classes which are in
directories defined as "script" directories. Thus, you can't, for
example, use a cayenne data object directly in rpc calls because
cayenne-related classes won't be found client side.
Some of the error reporting is opaque. You get exceptions like "an
uncaught exception was thrown on the server" sometimes a backtrace is
present, frequently it isn't. Often, even when it's present, the
exception is buried somewhere in the GWT compiler code, and no
indication of where the offending code can be found is proffered.
Overall, it seems like promising technology; I had a basic CRUD app with
some extra features tacked on in under two weeks; keep in mind that a) I
was learning the framework during that time, as well, and b) I'm a grad
student currently doing research over the summer, so all work on this
app was during my spare time, which frequently isn't readily available.
I think that frameworks like tapestry could learn a lot from GWT in
terms of ease of grasping the overall development model. On the other
hand, I think that tapestry does a superior job of separation of
concerns, making it easier for the Graphic designers to do their job,
and the coders theirs.
HTH.
Robert
Warner Onstine wrote:
> Don't know how many of you saw this, but it looks pretty cool (haven't
> had a chance to install on my windows box yet as that and Linux are the
> only ones supported right now).
>
> http://code.google.com/webtoolkit/
>
> From early reactions this seems like something very cool:
>
> http://jroller.com/page/RickHigh?entry=javaone_update_google_rocks
> http://jroller.com/page/RickHigh?entry=javaone_2006_google_s_gwt
> http://ajaxian.com/archives/google-web-toolkit-ajax-apps-from-java
>
> Anyone had a chance to play with this, share their experience in a brief
> 15 minute intro next meeting?
>
> -warner
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
