Congratulations! I'll try to give this a swing this week or next week, I hope it doesn't break the gwt-maven plugin too badly. Does anyone know when this milestone will hit the central Maven repo?
-- Arthur Kalmenson On Wed, Feb 4, 2009 at 7:34 PM, Scott Blum <sco...@google.com> wrote: > Greetings GWT developers, > The GWT team is happy to announce the availability of 1.6 Milestone 1! > Binary distributions are available for download directly from GWT's Google > Code project. > http://code.google.com/p/google-web-toolkit/downloads/list?can=1&q=1.6.0 > As always, milestone builds like this are use-at-your-own-risk. There are > known bugs, and it definitely isn't ready for production use. Please expect > some trial and error getting everything to work. The javadoc that comes > bundled with the distribution should be up-to-date, but the online Developer > Guide (http://code.google.com/docreader/#p=google-web-toolkit-doc-1-6) is > still very much a work in progress. We will be updating it over the next > several weeks. In lieu of an up-to-date Developer Guide and release notes, > below are the major highlights relative to GWT 1.5.3. > *** New Project Structure in GWT 1.6 *** > One of the biggest changes to GWT 1.6 is a new project structure. The old > output format has been replaced by the standard Java web app expanded "war" > format, and the actual directory name does default to "/war". Note that the > war directory is not only for compiler output; it is also intended to > contain handwritten static resources that you want to be included in your > webapp alongside GWT modules (that is, things you'd want to version > control). Please also note that the "GWTShell" and "GWTCompiler" tools will > maintain their legacy behavior, but they have been deprecated in favor of > new "HostedMode" and "Compiler" tools which use the new war output. When 1.6 > is officially released, we will be encouraging existing projects to update > to the new directory format and to use the new tools to take advantage of > new features and for compatibility with future GWT releases. > The sample projects provided in the GWT distribution provide an example of > correct new project configurations. For more details on the specifics of the > new project format, please see GWT 1.6 WAR design document > (http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6). > A couple of important changes we should highlight here: > - Projects with server-side code (GWT RPC) must configure a "web.xml" file > at "/war/WEB-INF/web.xml". This web.xml file must define and publish any > servlets associated with the web application. See the included DynaTable > sample. Additionally, server-side library dependencies must be copied into > "/war/WEB-INF/lib". For example, any GWT RPC servlets must have a copy of > gwt-servlet.jar in this folder. > - HTML host pages will no longer typically be located in a GWT module's > public path. Instead, we'll be recommending that people take advantage of > the natural web app behavior for serving static files by placing host pages > anywhere in the war structure that makes sense. For exmaple, you might want > to load a GWT module from a JSP page located in the root of your web app. To > keep such handwritten static files separate from those produced by the GWT > compiler, the latter will be placed into module-specific subdirectories. Any > page that wishes to include a GWT module can do so via a script tag by > referencing the GWT-produced "<module>.nocache.js script" within that > module's subdirectory. As of 1.6, we'll be recommending that only > module-specific resources used directly by GWT code, such as image files > needed by widgets, should remain on the public path. See the included > Showcase sample for some examples of this distinction. > - When you do need to load resources from a module's public path, always > construct an absolute URL by prepending GWT.getModuleBaseURL(). For example, > 'GWT.getModuleBaseURL() + "dir/file.ext"'. This advice has not changed, but > in the past it was easy to be sloppy with this, because the host page and > GWT module typically lived in the same directory, so using a relative URL > would usually do the right thing. Now that GWT modules live in a > subdirectory, you must reference public resources through > GWT.getModuleBaseURL(). > *** Hosted Mode Enhancements *** > Although the legacy GWTShell still uses an embedded Tomcat server, the new > HostedMode runs Jetty instead. There is also a new "Restart Server" button > on the main hosted mode window. Clicking this button restarts the internal > Jetty server, which allows Java code changes to take effect on the server > without having to completely exit and restart hosted mode. This is useful > when making code changes to RPC servlets, or when serializable RPC types are > modified and the server and client are out of sync. > *** New EventHandler System *** > Event handlers have been added to replace the old event listeners used by > Widgets, History, and various other classes. The new system has a few > differences from the old system: > - EventHandler methods always take a single parameter: the GwtEvent that the > Widget fired. For example, ClickHandler has a single method > onClick(ClickEvent). > - Each GwtEvent contains accessors relevant to the event, such as the key > that was pressed on KeyEvents. Native events provide access to the > underlying native event object. > - Each EventHandler defines only one method, so you do not need to create > empty methods just to satisfy the interface requirements. > For users who create their own Widgets, you no longer need to manage > listeners manually. Every Widget has a HandlerManager that manages all of > its handlers. For native events, such as ClickEvent, just call > addDomHandler() from within your code to register a handler and sink the > associated event on the Widget. When the native event is detected, the > handler will automatically be called. For logical events, such as > SelectionEvent, call addHandler() and fire the event manually using the > fireEvent() method. > You can see examples of EventHandler usage in many of the updated GWT > widgets and samples, or in new projects created with the new webAppCreator > tool. > You can now trigger a native event on almost any Element. Create a new > native event using the Document.create*Event() methods, then dispatch it on > a specific Element by calling Element.dispatchEvent(). These methods allow > you to expand your test coverage in ways that were previously impossible. > *** New Widgets *** > DatePicker > The new DatePicker and DateBox widgets allow your users to select a date > from a calendar. The Showcase sample provides examples of both of these > widgets. > LazyPanel > The new LazyPanel widget allows you to delay the creation of certain > sections of your application until they are first accessed, improving > startup performance. For example, if your application has a seldom used > "Help" section, you can wrap it in a LazyPanel and create the user interface > only if and when the user tries to access it. To use the LazyPanel, extend > the class and override the abstract createWidget() method. The > createWidget() method will be called the first time you call setVisible() on > the LazyPanel. > *** Fixed Issues *** > Please see our bug tracker for a full list of fixed issues and enhancements > (http://code.google.com/p/google-web-toolkit/issues/list?can=1&q=status:Fixed,FixedNotReleased%20milestone:1_6_RC&num=1000). > > As always, please report bugs to our issue tracker > (http://code.google.com/p/google-web-toolkit/issues/list) after doing a > quick search to see if your issue has already been reported. > Happy coding, > Scott, on behalf of the GWT team > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
