Adam Tacy

Originally posted by Jeanne Boyarsky:
First, a big thanks to Robert Hanson & Adam Tacy for being here to promote the book GWT In Action.

Thanks for the opportunity - there were some very interesting questions, and it was fun answering them all!

Originally posted by Jeanne Boyarsky:

The winners are:

Bill Barbour
Eric Pascarello
Rajeev Ja
William Brogden

Congratulations; hope the book is useful and that you get the chance to build some exciting GWT applications in the near future

//Adam

Originally posted by Rohan Dhruva:
Hi Authors (if you are still hanging around)

Does the book - GWT in Action - cover using GWT with Eclipse ? From the google site of GWT, it's clear that eclipse is the preferred IDE for developing with GWT - does the book cover this portion ?

Thanks.

Hi Rohan,

Yes it does try and weave in Eclipse aspects - mainly in the first couple of chapters where it talks about creating the basic "default" application using the GWT creation tools, together with the special switches you can provide them if you are going to be using Eclipse.

That's not to say the book is Eclipse focussed, we do talk about some of the other tools and approaches.

//Adam

..and the Observable class:

import java.util.Iterator;
import java.util.Vector;

public class Observable {

private boolean changed;
private Vector observers;

public void addObserver(Observer observer){
if (observer==null)
throw new RuntimeException();
observers.add(observer);
}

public void removeObserver(Observer observer){
observers.remove(observer);
}

public void removeObservers(){
observers.clear();
}

public void clearChanged(){
changed = false;
}

public void setChanged(){
changed = true;
}

public boolean hasChanged(){
return changed;
}

public void notifyObservers(){
notifyObservers(null);
}

public void notifyObservers(Object obj){
if(hasChanged()){
for (Iterator it = observers.iterator(); it.hasNext() {
Observer observer = (Observer) it.next();
observer.update(this,obj);
}
}
}

public Observable(){
// Create an empty list of observers.
observers = new Vector();
}
}

Here's the Observer interface

public interface Observer {
public void update(Observable observable, Object arg);
}

Originally posted by G M S:
Is there a way in GWT by which I can queue to service calls in FIFO.

No, not as a strict answer to your question. GWT has a concept of DeferredCommand which defers a particular command you have until after all the existing event handlers have executed, but is not necessarily what you are after, I feel.

my problem

I need to call two service
1. void updateModel(....)
2. refreshSomeView(....)

it is critical that refreshSomeView is called only after updateModel.

How can I ensure this

Your using standard Java so just make use of the Observer pattern.

Whilst you don't have the Java 1.4.2 java.util.Observer classes etc, they are trivial to implement yourself - I'll post the ones I use after this post.

To use create a class that represents your model and extends Observable; every change you make in the model call the notifyObservers() method. Your "view" would then implement the Observer interface that provides the update() method that updates your view.

When the model is updated, the view's update() method is automatically called, thus achieving what you are after.

(Of course some people could (would?) argue over my interpretation of the Observer pattern, but it works fine for me).

//Adam

Originally posted by John Todd:
Ok, any ideas how to create widgets like "Labels" or "Invite a friend" of GMail?

As a very basic view, they both look like they would fit within the new GWT RC1.4 DisclosurePanel (which would give the arrow, the title and the hidden/shown content- you would use styling to set the border and colours - and if you wanted the round corners, then that is some more CSS trickery that you can find on the web).

The contents of that DisclosurePanel would of course be different:

* "Labels" would probably be a VerticalPanel containing GWT Labels, these Labels would probably be created from data fed from a server call;
* "Invite a friend" would be a simple form.

At least that is how I would probably make my first attempt.

//Adam

Originally posted by John Todd:
Hi.
I remember I read an article about how to springify GWT RPC servlets in the past.
I have been looking at your book TOC and it seems to me that you didn't discuss that (Spring + GWT).
May I ask why as Spring is one of the hottest things these days?
Appreciate your help.

Book size, really - there were quite a lot of things we couldn't get into this book.

Robert's blog has an article on the changes in GWT 1.4 that make GWT/Spring integration easier - and the exceptionally useful GWT Spring library by George Georgovassilis can be found in the GWT Widget Library sourceforge area along with a users guide.

Hope that helps!

//Adam

Originally posted by Shawn Kuenzler:
What do you foresee for GWT in the job-marketplace?

It would be nice to have a crystal ball...

I wonder how well it will be adopted for development in larger shops.[/QB]

There are distinct benefits of GWT when it comes to developing serious web applications - tool support and theoretical reduced through life costs, etc - so it should become adopted quick quickly.

Whether it does is a matter for guessing at this moment in time.

Basically, with GWT doing so much of the work behind the scenes, if I invest my time learning it, will potential employers frown on the fact that I don't truly know AJAX?
Thanks![/QB]

You still need to know the concepts and understand the AJAX techniques to use GWT.

However, if you just learn GWT and then apply for a job that really requires you to program your own cross-browser Asynchronous program in JavaScript which handles XML in JavaScript code you will be at a disadvantage.

I think once you use and understand GWT would be able to explain to potential/current employers the key benefits of GWT and guide them into using GWT as the main approach.

//Adam

Originally posted by John Todd:

So, I have to create a hidden frame and assign an ID to it in my GWT host page?

You don't have to worry about it; GWT will create the frame for you if you just use the constructor FormPanel().

However, GWT gives you the option of creating a frame yourself if you want, and then you can pass that (or a reference to _self/ _top etc) to the constructor of the FormPanel - this can actually be useful for debugging if you want to see the actual raw data being returned by your service.

Originally posted by John Todd:

In case GWT will create it on the fly, how I'm supposed to access it with DOM since I don't its ID or name?

Again, you don't have to worry. In the the actual FormHandler onSubmitComplete() method you get access to the results through a FormSubmitCompleteEvent object that is passed in as a parameter - I was being a bit lazy with the method definition, in reality you would have:

form.addFormHandler(new FormHandler() {
public void onSubmitComplete(FormSubmitCompleteEvent event) {
String result = event.getResults());
}

public void onSubmit(FormSubmitEvent event) {
}
});

The onSubmitComplete() method is called by GWT code when the form submission is completed and GWT passes in a FormSubmitCompleteEvent object from which you can access the contents of the hidden frame - through that event's getResults() method.

//Adam

Originally posted by Daniel Moore:
Hi folks,
I was wondering what the biggest incompatibility you've seen between java (the JRE and the language) and GWT generated javascript (running in web mode)?

There is a small list of issues that might cause confusion between Java and JavaScript here:

http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.JavaToJavaScriptCompiler.LanguageSupport.html

But as Rob says it is very few.

//Adam

Originally posted by Roger F. Gay:
So, re: the examples - I often feel (as I know many do) that it would be nice in at least some situations, to be able to jump right in with a related example and just customize to get what I want.

...also the examples in the book are all available in electronic format so it is really easy to just grab the code and tweak to see what your additions will do (you get the code for all this application and more: http://dashboard.manning-sandbox.com)

//Adam

Originally posted by Charles McGuire:
Does Google have any statements or guiding principals about the support of existing API's as new releases are rolled out?

I don't recall seen anything written down directly as a statement, but everyone is very careful / aware of breaking API changes. A lot of discussion goes on on the contributor group (since GWT is now Open Source) http://groups.google.com/group/Google-Web-Toolkit-Contributors regarding changes and impacts.

Originally posted by Charles McGuire:
What has been the experience to this point?

Release 1.4 broke the approach to constructing a JSNI JavaSciptObject - however it was widely discussed and announced and a small change in limited amount of code.

There are some other examples here:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/search?group=Google-Web-Toolkit-Contributors&q=breaking+api+change&qt_g=Search+this+group

Originally posted by Charles McGuire:
Are there "best practices" a GWT developer can do to insulate the apps from API changes through releases? If so, are they covered in the book?

Stay away from, or at least be highly aware of experimental aspects is really the best advice.

GWT contributors also make the best attempts to protect you too - most of GWT is stable but in the latest release there are a couple of widgets where the internals are not completely sorted out. Methods affected in this case they have been marked final to prevent eager people subclassing minimising the chance of being caught out if changes occur in future release.

There is also the potential for a tool being developed to highlight such issues (see Bruce Johnson's post above the post in this link http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/215a21405162fdd2/e337ebef1684fd36?lnk=gst&q=breaking+api+change&rnum=8#e337ebef1684fd36)

//Adam

Originally posted by gary fong:

My question is can GWT be used as the cornerstone technology for a large-scale web application such as ours?

It can certainly be used as a cornerstone for large scale apps - I would go as far to say that the tool support you can harness go a long way towards resolving some of the issues you mention in your post "a big unmaintainable, rigid, fragile mess".

Originally posted by gary fong:
What are some of the downsides?

For me the biggest current drawback, when looking at complex apps, is there is no native modularization to loading your application - i.e. you typically have to download the whole application. The more complex/larger you app becomes the larger this download will becomes.

There are design ways around this, but it would be nice to have it supported natively.

For the majority of applications the above is not a massive problem once the GWT compiler mashes its way through your code stripping out unwanted aspects and cutting down, but at some point it becomes a consideration.

Originally posted by gary fong:
Also, how can GWT be introduced slowly, over a period of releases?

This will probably become the million dollar question as GWT gets more and more adoption; and the answer is going to be very dependent upon the starting point.

It's hard to give strict guidelines, but here are some thoughts I've used in the past...

Client "look and feel" has two extremes:

If your application is divided into well isolated components, then a strategy could be to replace these components release by release:

* components can be placed in a page using the standard GWT's ability to place elements at named DOM elements,
* you could link your existing code via JavaScript and JSNI (e.g. let your GWT component expose an API or harnessing the new "mashable" code from GWT 1.4 for JavaScript to GWT comms and using JSNI for the other way around).

At the other end, if the application is really spaghetti like, then it might be easier just starting all over again.

Another consideration is where you store the model; other technologies/toolkits/framwork tend to have the model on the server, with GWT it becomes more natural to migrate the model towards the client (though not necessarily completely to the client).

Any migration strategy would also have to think about moving the model location, as well as how to maintain consistency if the old approach has the model on the server and the new one moves it more to the client.

When moving the model, you also need to start thinking about granularity of saving the information to the server - too low and you have a high amount of network traffic; too low and the user risks loosing data.

As you are thinking about migrating you could also consider making the client/server interfaces you will end up with more robust or open, such as moving from hidden frame JSP request to GWT's RPC, or using JSON/XML etc - though maybe simple "Ajax" updates are enough.

The final issue I want to mention about migration is you need to think about what you will do with those ActiveX aspects, etc, that you mention. Can you perform the same tasks in JavaScript or do you need the ActiveX. That could restrict your options in migration, or require you learn a little more on JSNI.

Not knowing your application, but one approach might be to look at migrating it page by page - creating a GWT application per page; this way you minimise the model issue (since you can have whatever model you need on the client side per page, and then before moving page, you could refresh your "overall" model on the server, and I would imagine that each page is relatively isolated.

Once you have all pages migrated, you could then look at packaging pages together into meatier GWT applications; this would reduce round trips to the server and start reducing the number of GWT applications you have ended up with from the first step.

Of course, this might not be applicable for your app - it's hard to tell from the description, but it might be a way to start thinking.

Hope some of that is useful!!

//Adam

Originally posted by Jeanne Boyarsky:

1) Since the JavaScript is generated from Java, it reminds me a bit of servlets. Does this mean the presentation (HTML) in Java rather than just the JavaScript?

Actually the Java is only used during the development phase, once you hit the compile button the result is pure JavaScript that manipulated the DOM and makes use of CSS for styling.

Originally posted by Jeanne Boyarsky:

2) There is a different JavaScript file generated for each browser. Does this mean you have to redeploy when the next version of each browser comes out?

It mostly depends on what the next version of the browser does to its underlying handling of the DOM.

If it is the same as the previous version then No, if it changes, then first someone will have to implement the necessary GWT DOM classes and then Yes, you would have to recompile and redeploy.

This makes it slightly different to other approaches where you might just link to a new JavaScript library, but compiling and redeploying is not a substantial amount of effort compared to the test phase you would go through (with both a GWT and a non GWT approach) to ensure your application still works in a new browser.

//Adam

Hi John,

This is a topic that I think needs more stats before it can be answered properly. The Google guys, like on the link Glen points to, say that GWT almost always beats hand written scripts etc, but figures are hard to come across.

As Glen mentions, there is a danger that given the ease of development there is a risk of throwing everything GWT has into your application so code will bloat, not due to GWT but just to using toys that may not have been used if it was more difficult to write.

GWTs approach aims to reduce size of output code as much as possible - each permutation only contains code for a particlar browser; the compiler aggressively removes unused Java code, unused i18n constants/messages are removed etc.

This article on this blog, http://timepedia.blogspot.com/2007/06/gwt-demystified.html, gives a good idea on what the compiler does and actually lists figures of source code versus compiler code sizes.

//Adam