GWT Beginner's Tutorial
Marty Hall
http://courses.coreservlets.com/Course-Materials/ajax.html#GWT-Basics
I would appreciate any feedback.
Cheers-
- Marty Hall (hall-at-coreservlets-dot-com)
Adam T
Interesting and nice to see some tutorial. There are though, a few
points that can be challenged; in broad chronological order:
* there is an assumption that you must use Java RPC for client-server
comms; with GWT you are free to use whatever server side technology
you like - standard servlets, PHP, Ruby, Perl, etc etc. GWT RPC is
just a (perhaps very) useful approach.
* "Non-web based development" - not strictly true, since the GWT
tools contain an embedded version of tomcat.
* Not sure what you mean about having to hack the JAR file for
deployment (in previous versions yes, but not aware you need to
anymore)
* "Difficult to integrate JavaScript tools" - I disagree: either use
JSNI yourself, or use a third party library (In fact, even for a
beginner tutorial, some mention of JSNI would be useful to help people
understand that they don't have to cut off all their previous
development). For example, GoogleMaps, Scriptaculous, Google AJAX
Search etc etc all have their own 3rd party wrappers which make
integration really really simple and programmable in your Java code.
You could even argue that the likes of Scriptaculous should be
replaced by native effects to ensure you gain the benefits of GWT's
static code an analysis to reduce downloadable code size; some
examples: http://jason.essington.googlepages.com/Effect.html,
http://www.zwitserloot.com/tipit-gwtlib/example/ and http://code.google.com/p/gwt-fx/
* "Only for Java Developers", see first comment.
* Management evaluation - this should actually be a simpler
discussion, since the arguments are for using strongly typed language,
and writing once for deployment across many platforms; thus potential
for reduced cost of development/maintenance/ownership etc. The only
time it gets difficult with "management" is if everyone else in your
group is completely welded to using JavaScript/HTML and are afraid of
the new simplification GWT brings along; or you have a poor argument
for GWT's ability to interface to legacy code you have. GWT also
allows the use of mature development tools such as Ant and Maven
(http://groups.google.com/group/gwt-maven).
* Your development steps consistently appear to imply that every GWT
widget will need it's own distinct DOM element it can be placed in,
e.g. a new DOM element for each ListBox etc. This could give a poor
impression of GWT and is not how real GWT applications are developed.
You could (should?) introduce the concepts of Panels and composite
widgets, which are generally used in real-life GWT applications
(http://groups.google.com/group/Google-Web-Toolkit/browse_thread/
thread/e461c8e96bf68b67/00347d3609bcfa48?lnk=gst&q=real
+world&rnum=4#00347d3609bcfa48) and talk about these Panels/Composites
being placed into a DOM element - in fact this is another good point
to explain how GWT can incrementally replace components on your
existing application.
* You probably need to update the tutorial pretty soon as the samples
are based on GWT 1.3 and 1.4 is only a few days away (e.g. no
"gwt:module" meta tag anymore etc)
* Actually, you get a bit of 1.4 in there when discussing the need
for complex data objects returned by server to implement Serializable
- maybe you should clarify by saying they must implement
IsSerializable, but from 1.4. you are allowed to use the interface tag
Serializable *but* do not expect the standard contract to be adhered
to as for 1.4 Serializable == IsSerializable and nothing more.
* You might want to mention the Same-Source origin constraint for
client-server communication, since that gets a lot of comments/
confusion on the development forum.
* You keep mentioning that server side classes must be in a "client"
package - true for default, but you don't mention you can change this
using definitions in GWT's Module file (come to think of it, you don't
really discuss this quite important "module" aspect at all - you could
introduce it when discussing the CSS as you can place the link to the
CSS in the GWT module file rather than in the HTML).
* Missing, in my view, are some mention/overview of:
* internationalization
* how GWT copes with browser differences
* XML and JSON processing
* JavaScript Native Interface (JSNI)
* GWT Module files, their use and purpose
Hopefully not too harsh and I hope that some of that helps!
Regards,
//Adam
Co-author of GWT In Action http://www.manning.com/hanson
GWT Example: http://dashboard.manning-sandbox.com
On May 28, 3:11 am, Marty Hall <javahac...@gmail.com> wrote:
> I put together an introductory tutorial on GWT, and posted it athttp://courses.coreservlets.com/Course-Materials/ajax.html#GWT-Basics
Marty Hall
appreciated! I will look closely at what you said and see what I can
correct and what suggestions I can incorporate. I think perhaps a few
of the topics you propose are (IMHO) too advanced for the goals of the
first part of my tutorial: a beginner's level getting-started guide,
but I will see what I can do on all the rest. Thanks!
I did have one concrete question now, though: you said you didn't have
to hack the JAR file any more, but in the version of 1.3 I downloaded
last week, gwt-user.jar still had the javax.servlet* classes in it.
So, the results I had were:
A) You couldn't deploy gwt-user.jar in WEB-INF/lib because it is
illegal to do so, and at least Tomcat 6 enforces this rule.
B) You can't deploy in common/lib because of classloader problems when
doing RPC.
Am I missing something in that regard? I might as well correct this
before I put the second section of the tutorial (server-side data)
online.
Cheers-
- Marty
PS I will rush out and buy your book.
On May 28, 2:07 am, Adam T <adam.t...@gmail.com> wrote:
> Hej Marty,
>
> Interesting and nice to see some tutorial. There are though, a few
> points that can be challenged; in broad chronological order:
>
> * there is an assumption that you must use Java RPC for client-server
> comms; with GWT you are free to use whatever server side technology
> you like - standard servlets, PHP, Ruby, Perl, etc etc. GWT RPC is
> just a (perhaps very) useful approach.
>
> * "Non-web based development" - not strictly true, since the GWT
> tools contain an embedded version of tomcat.
>
> * Not sure what you mean about having to hack the JAR file for
> deployment (in previous versions yes, but not aware you need to
> anymore)
>
> * "Difficult to integrate JavaScript tools" - I disagree: either use
> JSNI yourself, or use a third party library (In fact, even for a
> beginner tutorial, some mention of JSNI would be useful to help people
> understand that they don't have to cut off all their previous
> development). For example, GoogleMaps, Scriptaculous, Google AJAX
> Search etc etc all have their own 3rd party wrappers which make
> integration really really simple and programmable in your Java code.
> You could even argue that the likes of Scriptaculous should be
> replaced by native effects to ensure you gain the benefits of GWT's
> static code an analysis to reduce downloadable code size; some
Adam T
On May 28, 1:31 pm, Marty Hall <javahac...@gmail.com> wrote:
> ...I think perhaps a few of the topics you propose are (IMHO) too advanced for the goals of the first part of my tutorial: a beginner's level getting-started guide,
I think you're right if you are thinking I meant a detailed
description, but they are such useful and value-add things that a real
beginner's level guide would benefit even if just mentioning them
briefly.
> I did have one concrete question now, though: you said you didn't have to hack the JAR file any more, but in the version of 1.3 I downloaded last week, gwt-user.jar still had the javax.servlet* classes in it. So, the results I had were:
> A) You couldn't deploy gwt-user.jar in WEB-INF/lib because it is illegal to do so, and at least Tomcat 6 enforces this rule.
> B) You can't deploy in common/lib because of classloader problems when doing RPC.
>
> Am I missing something in that regard?
This used to be true, when some of the necessary rpc classes were in
gwt-user.jar; but a while back it was fixed (http://code.google.com/p/
google-web-toolkit/issues/detail?id=130) and now there is no need to
put gwt-user.jar in your deployment, you only have to use gwt-servlet
which does not contain the javax.servlet.* classes.
>
> Cheers-
> - Marty
>
> PS I will rush out and buy your book.
>
Great :-) hope you find it useful (I believe that it comes out of the
printers on Friday, although of course you can get an electronic copy
from the Manning site)
I look forward to seeing the second part of your tutorial!
//Adam
Sanjiv Jivan
- Being an experienced Java developer, I found it extremely easy to
pick up GWT. Almost everything made sense as I went through the
documentation, examples and GWT source. Working with GWT for building
rich web apps is more in line with how Java developers think and
program : separate classes, listeners, modular code etc. I picked up
GWT faster than any other Java or JS web framework (5 - 10 days) and
I've already made good progress on a pet project.
- Re: Hard to integrate JavaScript tools - I found this very easy to
do. Infact I'm using several components from other JS toolkits after
adding a GWT Widget wrappers around them. JSNI is wicked cool!!
- In your samples you have pre-existing placeholder divs that you
attach ListBoxes and other widgets to. I may be wrong here based on my
limited experience with GWT, but it seems like the GWT philosophy is
more to start with a near-blank "host page" and then add widgets to
Panels dynamically. That way the entire UI is javascript based and
does not rely on any static markup. Starting with a near-blank page
and building the UI entirely with Panels and Widgets seems better
suited as applications get larger as you're going to have several
pages, each with separate widgets and content and having placeholder
divs in the host page for widgets across pages is not practical. I can
think of a few other advantages of going with the Javascript only UI
1) GWT always requests the host page and then figures out based on the
lookup table whether it needs to fetch fresh content from the server
or if the code on the client side is current. Having a near-blank host
page will therefore improve performance as when the initial request
for the host page is made, less data is returned.
2) Using Adobe Apollo for converting a web app to run as a desktop app
gets easier when you do not rely on markup from the server to be part
of UI generation.
My 2c :)
Sanjiv
On May 27, 9:11 pm, Marty Hall <javahac...@gmail.com> wrote:
> I put together an introductory tutorial on GWT, and posted it athttp://courses.coreservlets.com/Course-Materials/ajax.html#GWT-Basics
qqc...@gmail.com
quite a lot just by reading the comments *about* the tutorial.
Getting great minds together in a very productive way like this is
what will eventually transform the world, IMO. I'm hoping someday
that other professions can learn by our example of how to synergize
effectively with other folks in the same field, all around the world.
Keep contributing, and keep the good feedback a comin!
Chuck
P.S. Marty, I already own one of your books, and Adam, I have an
electronic copy of yours ("GWT In Action...")and will be getting a
paper copy of yours as well. Keep up the good work you two!
Marty Hall
> > ...I think perhaps a few of the topics you propose are (IMHO) too advanced for the goals of the first part of my tutorial: a beginner's level getting-started guide,
>
> I think you're right if you are thinking I meant a detailed
> description, but they are such useful and value-add things that a real
> beginner's level guide would benefit even if just mentioning them
> briefly.
OK. Good advice. I will see what I can do!
> > I did have one concrete question now, though: you said you didn't have to hack the JAR file any more, but in the version of 1.3 I downloaded last week, gwt-user.jar still had the javax.servlet* classes in it. So, the results I had were:
> > A) You couldn't deploy gwt-user.jar in WEB-INF/lib because it is illegal to do so, and at least Tomcat 6 enforces this rule.
> > B) You can't deploy in common/lib because of classloader problems when doing RPC.
>
> > Am I missing something in that regard?
>
> This used to be true, when some of the necessary rpc classes were in
> gwt-user.jar; but a while back it was fixed (http://code.google.com/p/
> google-web-toolkit/issues/detail?id=130) and now there is no need to
> put gwt-user.jar in your deployment, you only have to use gwt-servlet
> which does not contain the javax.servlet.* classes.
Oh. News to me. Thanks very much!
> > PS I will rush out and buy your book.
>
> Great :-) hope you find it useful (I believe that it comes out of the
> printers on Friday, although of course you can get an electronic copy
> from the Manning site)
After I said I would rush out and buy your book, I discovered what you
said: that it is not shipping yet. But I will be first in the queue to
get it once it does ship. It looks like it will be great.
Thanks again for your advice.
Marty Hall
Others have suggested talking about panels earlier, so I will see what
I can do without compromising the intent of that section of the my
tutorial: making things very simple for beginners.
I am not so sure about the idea of generating the complete UI in GWT,
though (at least in a beginner's tutorial). It makes sense if you view
the end result as "an interface to a program". But it doesn't make so
much sense if you view the end result as "a Web page with some active
components". HTML is so much more productive for simple textual
markup. I suppose it depends on what types of applications you are
doing.
You mentioned Adobe Apollo, but I know nothing about it. Can you give
a two sentence summary of what Apollo is all about?
Cheers-
- Marty
Marty Hall
> * Management evaluation - this should actually be a simpler
> discussion, since the arguments are for using strongly typed language,
> and writing once for deployment across many platforms; thus potential
> for reduced cost of development/maintenance/ownership etc. The only
> time it gets difficult with "management" is if everyone else in your
> group is completely welded to using JavaScript/HTML and are afraid of
> the new simplification GWT brings along; or you have a poor argument
> for GWT's ability to interface to legacy code you have. GWT also
> allows the use of mature development tools such as Ant and Maven
> (http://groups.google.com/group/gwt-maven).
Maybe it *should* be a simple sell to management, but my observation
around here is that it isn't working in practice. I am NOT an Ajax
expert by any stretch of the imagination (I mostly do servlets, JSP,
Struts, and especially JSF). However, it doesn't seem that GWT is on
the radar screen around here. There are some big government
organizations around here that employ hundreds (literally) of J2EE
developers, and when I ask them or other organizations "what Ajax
toolkits are people using?", the answers I get are, in approximate
order:
- Ajax4JSF or IceFaces or Trinidad (aka Oracle ADF)
-- this response is for the JSF folks only
- Direct scriptaculous/Prototype calls, or maybe Dojo
- Direct Web Remoting or JSON in the above mix
- JSP custom tags wrapped around JavaSript calls
- The AjaxTags library
Hardly anyone even mentions GWT. Note that the audience for my
question are Java folks, so Ruby and PHP doesn't show up on the list
because of the people that are answering.
Anyhow, I think one reason GWT isn't being used here as much as I
would have expected is that it is a bigger change in approach than the
others, and that (IMHO) the current documentation does not make it
obvious to see how to do simple applications. That is one of the
things I am trying to combat with my tutorial.
Cheers-
- Marty
Marty Hall
On May 28, 9:10 pm, Sanjiv Jivan <sanjiv.ji...@gmail.com> wrote:
> JSNI is wicked cool!!
What is the best source to learn how to use JSNI with GWT? I am
looking to make examples that will seem simple to beginners and not
scare them away. So, simplicity is more important than power in the
examples I am looking for now.
Cheers-
Reinier Zwitserloot
utterly pointless and in fact backwards - they will cause your readers
to get turned OFF and wave it away as pointless frivolity.
In other words, the example needs as much zing as you can afford
without making it too complicated, and it definitely has to be
something that standard GWT just plain cannot do, at all.
A zingy effect would be to take an external JS widget, like a big
calendar type thing or some such, and use a lot of JSNI to create a
new Widget (public class MyCalendar extends Widget).
The simplest example that you can't do with GWT that might be useful,
but decidedly lacking in the zing, is:
public static native String getWindowUrl() /*-{
return window.location.href;
}-*/;
But that example will fall on its arse unless you show something cool
you can do with that. You could try and explain how you can use this
to parse out ? parameters, which is one option, I guess.
Sanjiv Jivan
Serializable *but* do not expect the standard contract to be adhered
to as for 1.4 Serializable == IsSerializable and nothing more. "
Do exceptions still need to implement SerializableException?
On May 28, 2:07 am, Adam T <adam.t...@gmail.com> wrote:
> Hej Marty,
>
> Interesting and nice to see some tutorial. There are though, a few
> points that can be challenged; in broad chronological order:
>
> * there is an assumption that you must use Java RPC for client-server
> comms; with GWT you are free to use whatever server side technology
> you like - standard servlets, PHP, Ruby, Perl, etc etc. GWT RPC is
> just a (perhaps very) useful approach.
>
> * "Non-web based development" - not strictly true, since the GWT
> tools contain an embedded version of tomcat.
>
> * Not sure what you mean about having to hack the JAR file for
> deployment (in previous versions yes, but not aware you need to
> anymore)
>
> * "Difficult to integrate JavaScript tools" - I disagree: either use
> JSNI yourself, or use a third party library (In fact, even for a
> beginner tutorial, some mention of JSNI would be useful to help people
> understand that they don't have to cut off all their previous
> development). For example, GoogleMaps, Scriptaculous, Google AJAX
> Search etc etc all have their own 3rd party wrappers which make
> integration really really simple and programmable in your Java code.
> You could even argue that the likes of Scriptaculous should be
> replaced by native effects to ensure you gain the benefits of GWT's
> static code an analysis to reduce downloadable code size; some
>
> * "Only for Java Developers", see first comment.
>
> * Management evaluation - this should actually be a simpler
> discussion, since the arguments are for using strongly typed language,
> and writing once for deployment across many platforms; thus potential
> for reduced cost of development/maintenance/ownership etc. The only
> time it gets difficult with "management" is if everyone else in your
> group is completely welded to using JavaScript/HTML and are afraid of
> the new simplification GWT brings along; or you have a poor argument
> for GWT's ability to interface to legacy code you have. GWT also
> allows the use of mature development tools such as Ant and Maven
> (http://groups.google.com/group/gwt-maven).
>
> * Your development steps consistently appear to imply that every GWT
> widget will need it's own distinct DOM element it can be placed in,
> e.g. a new DOM element for each ListBox etc. This could give a poor
> impression of GWT and is not how real GWT applications are developed.
> You could (should?) introduce the concepts of Panels and composite
> widgets, which are generally used in real-life GWT applications
> (http://groups.google.com/group/Google-Web-Toolkit/browse_thread/
> thread/e461c8e96bf68b67/00347d3609bcfa48?lnk=gst&q=real
> +world&rnum=4#00347d3609bcfa48) and talk about these Panels/Composites
> being placed into a DOM element - in fact this is another good point
> to explain how GWT can incrementally replace components on your
> existing application.
>
> * You probably need to update the tutorial pretty soon as the samples
> are based on GWT 1.3 and1.4is only a few days away (e.g. no
> "gwt:module" meta tag anymore etc)
>
> * Actually, you get a bit of1.4in there when discussing the need
> for complex data objects returned by server to implementSerializable
> - maybe you should clarify by saying they must implement
> IsSerializable, but from1.4. you are allowed to use the interface tagSerializable*but* do not expect the standard contract to be adhered
> to as for1.4Serializable== IsSerializable and nothing more.
Mark Volkmann
> Examples that don't actually give a taste of the power behind them are
> utterly pointless and in fact backwards - they will cause your readers
> to get turned OFF and wave it away as pointless frivolity.
>
> In other words, the example needs as much zing as you can afford
> without making it too complicated, and it definitely has to be
> something that standard GWT just plain cannot do, at all.
You can see a really simple example of using JSNI to do something
that GWT cannot at http://www.ociweb.com/mark/programming/
GWT.html#JavaScriptFromJava. It shows doing regular expression
matching from GWT Java code using JavaScript.
SeanC
able to easily unit test GWT code in my opinion is a major plus, and
is one of the main reasons I use GWT.
On May 28, 2:11 am, Marty Hall <javahac...@gmail.com> wrote:
> I put together an introductory tutorial on GWT, and posted it athttp://courses.coreservlets.com/Course-Materials/ajax.html#GWT-Basics
Ping
I think you're right when you say that GWT is not very mentioned... I
see 2 "problems" with gwt right now:
* There isn't a killer app developed by regular guys
* The documentation left many things out
Since gwt shares architecture with swing, I think it suffers from the
same problem: there isn't a clear way to organize things. Swing is
very elegant in my opinion, one reason is that it doesn't enforce a
developemnt style, but it is hard from newbies to figure out how to
start - I think gwt suffers the same. I guess that tutorials always
help ;)
By the way, I'm trying to develop a simple scheduling app with drag-n-
drop capabilities (kinda like gcalendar, but much more simpler of
course). If I ever get to something usable, I'll post a tutorial or
so.
Reinier Zwitserloot
On May 30, 3:36 pm, Ping <miguel.p...@gmail.com> wrote:
> Hi there,
>
> I think you're right when you say that GWT is not very mentioned... I
> see 2 "problems" with gwt right now:
> * There isn't a killer app developed by regular guys
> * The documentation left many things out
>
There's no killer app? Whuh?
gpokr.com works for me. Developed by 1 regular guy, in fact.
What did you feel is left out by the docs? There's some info missing
on how to interact with servers, perhaps, but people who actually know
web development either know that stuff already and know how to search
for that information. "Regular guys" with no programming skills
generally don't come up with 'killer apps' normally (except maybe
reddit, which is software-wise a big bag of crud, but the idea is nice-
ish).
> Since gwt shares architecture with swing, I think it suffers from the
> same problem: there isn't a clear way to organize things. Swing is
> very elegant in my opinion, one reason is that it doesn't enforce a
> developemnt style, but it is hard from newbies to figure out how to
> start - I think gwt suffers the same. I guess that tutorials always
> help ;)
GWT enforces plenty of architecture. I think it would help if you give
us some examples of what you mean.
>
> By the way, I'm trying to develop a simple scheduling app with drag-n-
> drop capabilities (kinda like gcalendar, but much more simpler of
> course). If I ever get to something usable, I'll post a tutorial or
> so.
Well, if you start doing things not integrated into gwt yet (like
DnD), you're bound to run into spots where you will need to experiment
a bit and do some reading.
Sanjiv Jivan
as it has some neat features. However I wouldn't really call it a
killer app. Its pretty simple and rough around the edges. Its nowhere
near the quality of some other flash based online poker sites.
Something like gmail written in GWT would be a killer app IMO.
Sanjiv
Reinier Zwitserloot
No worries though. We'll be conquering the world soon with a GWT based
webapp: http://tipit.to/
Marty Hall
(http://courses.coreservlets.com/Course-Materials/ajax.html#GWT-
Basics).
I also added a new section on RPC, also aimed at beginners.
Any further feedback would be much appreciated.
amic...@gmail.com
> Google Checkout. MyHippocampus. Queweb.
>
> No worries though. We'll be conquering the world soon with a GWT based
> webapp:http://tipit.to/
How do you prevent people from tipping themselves large amounts to
gain recognition?
How do you prevent people from getting large amounts from friends and
then paying them back?
Amir
Sanjiv Jivan
not an accurate statement, certainly not for Java developers. Even if
I was attending a Tapestry class, I wouldn't want to see one of the
first slides say that it has a big learning curve ;) Maybe after the
class the audience can decide if GWT is their cup of tea.
I do agree that the deployment can be a little cumborsome.
Sanjiv
Marty Hall
On Jun 6, 5:32 pm, Sanjiv Jivan <sanjiv.ji...@gmail.com> wrote:
> I still think that "Big learning curve" listed as a disadvantage is
> not an accurate statement, certainly not for Java developers. Even if
> I was attending a Tapestry class, I wouldn't want to see one of the
> first slides say that it has a big learning curve ;) Maybe after the
> class the audience can decide if GWT is their cup of tea.
Well, the tact I take is to *not* try to be an advocate for a
particular technology, but rather summarize what I think are the pros
and the cons as accurately as possible at the beginning. Besides, I
think in the long run people will be more satisfied if they have
realistic expectations at the beginning.
The single most common course I teach is on JSF, and I get so many
requests for JSF training courses that I can hardly keep up. (A course
Down Under in Sydney is next: yay!). But you should see all the
negatives I cite about JSF early on. I am much harsher than I am with
GWT. In general, I think it is unhelpful to potential developers if
you cite the advantages without also citing the disadvantages.
Anyhow, back to "big learning curve", I still think this is true. With
most other Ajax tools, developers start with what they already know
(xhtml, JavaScript, maybe JSP custom tags) and add in a few things.
With GWT, they have to think in a whole new way, and they have to
learn a new class for each xhtml form element that they already knew.
Now, I think this is *more* productive in the medium and long term,
but, still, my empirical observation is that people who start with GWT
take longer to get going *initially* than they do with other Ajax
tools. Instead of denying this initial ramp up time, I think it is
better to argue that it is well worth it in the medium to long term.
Or even in the just-a-bit-longer-than-short term. :-)
mP
On Jun 8, 5:15 am, Marty Hall <javahac...@gmail.com> wrote:
> On Jun 6, 5:32 pm, Sanjiv Jivan <sanjiv.ji...@gmail.com> wrote:
>
> > I still think that "Big learning curve" listed as a disadvantage is
> > not an accurate statement, certainly not for Java developers. Even if
> > I was attending a Tapestry class, I wouldn't want to see one of the
> > first slides say that it has a big learning curve ;) Maybe after the
> > class the audience can decide if GWT is their cup of tea.
>
> Well, the tact I take is to *not* try to be an advocate for a
> particular technology, but rather summarize what I think are the pros
> and the cons as accurately as possible at the beginning. Besides, I
> think in the long run people will be more satisfied if they have
> realistic expectations at the beginning.
>
> The single most common course I teach is on JSF, and I get so many
> requests for JSF training courses that I can hardly keep up. (A course
> Down Under in Sydney is next: yay!).
Dont come you wont like it here :)
