Revision: 6950
Author: br...@google.com
Date: Mon Nov 16 19:02:31 2009
Log: Getting started notes
http://code.google.com/p/google-web-toolkit/source/detail?r=6950

Added:
  /wiki/GWT_2_0_RC.wiki

=======================================
--- /dev/null
+++ /wiki/GWT_2_0_RC.wiki       Mon Nov 16 19:02:31 2009
@@ -0,0 +1,26 @@
+#summary Getting Started with the GWT 2.0 Release Candidate
+
+= 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.
+  * Changes to the distribution: Note that there's only one download, and  
it's no longer platform-specific. You download the same zip file for every  
development platform. This is made possible by the new plugin approach used  
to implement development mode (see below). The distribution file does not  
include the browser plugins themselves; those are downloaded separately the  
first time you use development mode in a browser that doesn't have the  
plugin installed.
+
+=== 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 with <a  
href="http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/core/client/GWT.html#runAsync(com.google.gwt.core.client.RunAsyncCallback)">GWT.runAsync()</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.
+  * 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.
+
+=== 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.
+  * Also due to the "development mode" terminology change, the name of the  
ant build target produced by `webAppCreator` has changed from `hosted` to  
`devmode`. In other words, to start development mode from the command-line,  
type `ant devmode`.
+  * !HtmlUnit does not attempt to emulate authentic browser layout.  
Consequently, tests that are sensitive to browser layout are very likely to  
fail. However, since GWTTestCase supports other methods of running tests,  
such as Selenium, that do support accurate layout testing, it can still  
make sense to keep layout-sensitive tests in the same test case as  
non-layout-sensitive tests. If you want such tests to be ignored  
by !HtmlUnit, simply annotate the test methods with  
@!DoNotRunWith({Platform.!HtmlUnit}). Versions of Google Plugin for Eclipse  
prior to 1.2 will only allow you to add GWT release directories that  
include a file with a name like `gwt-dev-windows.jar`. You can fool it by  
sym linking or copying gwt-dev.jar to the appropriate name.
+  * The way arguments are passed to the GWT testing infrastructure has  
been revamped. There is now a consistent syntax to support arbitrary "run  
styles", including user-written, with no changes to GWT itself. For  
example, `-selenium FF3` has become `-runStyle selenium:FF3`. This change  
likely does not affect typical test invocation scripts, but if you do use  
`-Dgwt.args` to pass arguments to GWTTestCase, be aware that you may need  
to make some changes.
+
+

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to