Revision: 6954
Author: br...@google.com
Date: Mon Nov 16 19:44:49 2009
Log: Added getting started instructions
http://code.google.com/p/google-web-toolkit/source/detail?r=6954
Modified:
/wiki/GWT_2_0_RC.wiki
=======================================
--- /wiki/GWT_2_0_RC.wiki Mon Nov 16 19:20:19 2009
+++ /wiki/GWT_2_0_RC.wiki Mon Nov 16 19:44:49 2009
@@ -3,7 +3,7 @@
= Getting Started with GWT 2.0 RC1 =
This release contains big changes to improve developer productivity, make
cross-browser development easier, and produce faster web applications.
-
+
=== Things that are changing with GWT 2.0 that might otherwise be
confusing without explanation ===
* Terminology changes: We're going to start using the term "development
mode" rather than the old term "hosted mode."
* The term "hosted mode" was sometimes confusing to people, so we'll be
using the more descriptive term "development mode" from now on. For similar
reasons, we'll be using the term "production mode" rather than "web mode"
when referring to compiled script.
@@ -12,10 +12,37 @@
=== Major New Features ===
* In-Browser Development Mode: Prior to 2.0, GWT hosted mode provided a
special-purpose "hosted browser" to debug your GWT code. In 2.0, the web
page being debugged is viewed within a regular-old browser. Development
mode is supported through the use of a native-code plugin called
the "Google Web Toolkit Developer Plugin" for many popular browsers. In
other words, you can use development mode directly from Safari, Firefox,
IE, and Chrome.
* Code Splitting: Developer-guided code splitting using GWT.runAsync(),
along with compile reports (also known as <a
href="http://code.google.com/events/io/2009/sessions/StoryCompilerGwtCompiler.html";>The
Story of Your Compile</a>) allows you to chunk your GWT code into multiple
fragments for faster startup. Imagine having to download a whole movie
before being able to watch it. Well, that's what you have to do with most
Ajax apps these days -- download the whole thing before using it. With code
splitting, you can arrange to load just the minimum script needed to get
the application running and the user interacting, while the rest of the app
is downloaded as needed.
- * Declarative User Interface: GWT's <a
href="http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/uibinder/client/UiBinder.html";>UiBinder</a>
now allows you to create user interfaces mostly declaratively. Previously,
widgets had to be created and assembled programmatically, requiring lots of
code. Now, you can use XML to declare your UI, making the code more
readable, easier to maintain, and faster to develop. The Mail sample has
been updated to show a practical example of using !UiBinder.
+ * Declarative User Interface: GWT's <a
href="http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/uibinder/client/UiBinder.html";>!UiBinder</a>
now allows you to create user interfaces mostly declaratively. Previously,
widgets had to be created and assembled programmatically, requiring lots of
code. Now, you can use XML to declare your UI, making the code more
readable, easier to maintain, and faster to develop. The Mail sample has
been updated to show a practical example of using !UiBinder.
* Bundling of resources via <a
href="http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/resources/client/ClientBundle.html";>!ClientBundle</a>.
GWT introduced <a
href="http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/user/client/ui/ImageBundle.html";>!ImageBundle</a>
in 1.4 to provide automatic spriting of images. !ClientBundle generalizes
this technique, bringing the power of combining and optimizing resources
into one download to things like text files, CSS, and XML. This means fewer
network round trips, which in turn can decrease application latency --
especially on mobile applications.
* Using !HtmlUnit for running test cases based on <a
href="http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/junit/client/GWTTestCase.html";>GWTTestCase</a>:
Prior to 2.0, GWTTestCase relied on SWT and native code versions of actual
browsers to run unit tests. As a result, running unit tests required
starting an actual browser. As of 2.0, GWTTestCase no longer uses SWT or
native code. Instead, it uses !HtmlUnit as the built-in browser.
Because !HtmlUnit is written entirely in the Java language, there is no
longer any native code involved in typical test-driven development.
Debugging GWT Tests in development mode can be done entirely in a Java
debugger.
-
+
+=== Getting Started with Development Mode ===
+==== Step 1: Start Development Mode ====
+The first time you launch development mode in GWT 2.0, you might be
surprised that not much seems to happen.
+All you will see is something like this on the console:
+{{{
+Using a browser with the GWT Developer Plugin, please browse to
+the following URL:
+ http://localhost:8888/Hello.html?gwt.codesvr=192.168.1.42:9997
+}}}
+That's because you're now in control over which target browser launches
and when.
+
+==== Step 2: Open a browser ====
+Open the browser you want to use to view the GWT application you're
debugging.
+
+If this is the first time you've ever attempt to use development mode with
that browser, you will not yet have the GWT Developer Plugin installed, so
you'll see a page that instructs you to install the plugin. Once you
download and install the plugin, restart the browser and navigate again to
the URL from above, making sure it includes the `gwt.codesvr` query
parameter.
+
+Note that the first time you access your GWT module from a browser, it may
appear to hang momentarily as your module loads. This is normal. Subsequent
refreshes within the browser are much faster as long as you keep the
development mode session running.
+
+==== Step 3: Follow the Edit/Save/Refresh cycle without restarting
development mode ====
+At this point, use your Java debugger as normal.
+
+Because refeshes are much faster than the initial load, it is strongly
recommended that you simply leave development mode running, because you can
continue to edit and save any of your projects files -- including `.html`,
`.css`, `.java`, `.gwt.xml`, and `.ui.xml` files -- and simply refresh to
pick up changes.
+
+==== Step 4: Open additional browsers for testing ====
+You can open any number of additional browsers to ensure your application
behaves properly across browsers.
+
+
=== Breaking changes and known issues/bugs/problems ===
* Prior to 2.0, GWT tools such as the compiler were provide in a
platform-specific jar (that is, with names like `gwt-dev-windows.jar`). As
of 2.0, GWT tools are no longer platform specific and they reside in
generically-named `gwt-dev.jar`. You are quite likely to have to update
build scripts to remove the platform-specific suffix, but that's the extent
of it.
* The development mode entry point has changed a few times since GWT
1.0. It was originally called `GWTShell`, and in GWT 1.6 a replacement
entry point called `HostedMode` was introduced. As of GWT 2.0, to reflect
the new "development mode" terminology, the new entry point for development
mode is `com.google.gwt.dev.DevMode`. Sorry to keep changing that on ya,
but the good news is that the prior entry point still works. But, to really
stay current, we recommend you switch to the new `DevMode` entry point.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
