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.
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.
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. If you run into a serious issue, feel free to also reply back to this thread.
Waiting for quite sometime, and I'm targeting 1.6 to build my GDE
project for quite some time, and finally, got a milestone release
ready. :) Great News!
On Feb 6, 11:26 pm, Scott Blum <sco...@google.com> wrote:
> 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.
> 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.
> 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. If you run into a
> serious issue, feel free to also reply back to this thread.
> Happy coding,
> Scott, on behalf of the GWT team
> 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.
> 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.
> 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. If you run into a
> serious issue, feel free to also reply back to this thread.
> Happy coding,
> Scott, on behalf of the GWT team
> 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.
> 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.
> 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. If you run into a
> serious issue, feel free to also reply back to this thread.
> Happy coding,
> Scott, on behalf of the GWT team
On Sun, Feb 8, 2009 at 8:28 AM, Samyem Tuladhar <sam...@gmail.com> wrote:
> Great! I was wondering if this version supports OOPHM?
> Thanks,
> Samyem
> On Feb 6, 10:26 am, 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.
>> 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.
>> 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. If you run into a
>> serious issue, feel free to also reply back to this thread.
>> Happy coding,
>> Scott, on behalf of the GWT team
Hi - I've perused the WAR Design document, but I've several questions that
remained unanswered.
In my project, we use GWT-SL and Gilead - the former for exporting Spring
beans as GWT-RPC services, and the latter for transferring Hibernate-enabled
objects back and forth between the server and client.
A consequence of using GWT-SL is that I no longer map my servlets through
web.xml - instead, I've a springDispatcher servlet which receives all
requests and routes them to the appropriate service exports I've defined
with GWT-SL, using the SimpleUrlHandlerMapping which Spring provides.
Now, since I'd like to route only GWT-RPC (and servlet) requests through the
Dispatcher servlet, I've only routed /services/* to it.
The difficulty arises when using Hosted Mode. First, I have to copy a
modified web.xml to ${project}/tomcat/webapps/ROOT. This web.xml routes all
requests to /services/* to my springDispatcher. This web.xml is different
than the one I distribute with my WAR, since it also includes mapping for
the GWTShellServlet. Also, in order for serialization to work, I have to
compile my project once (using GWTCompiler) and copy all resulting *.gwt.rpc
files to ${project}/tomcat/webapps/ROOT/${module}/. This occurs because the
GWTShellServlet generates these dynamically as GWT-RPC requests arrive.
I've semi-automated the whole process using Ant tasks, and I'm aware of the
gwt-maven plugin which provides some of this functionality, but I'd like to
know whether the situation has been fully or partly addressed with the 1.6
release.
On Sun, Feb 8, 2009 at 6:41 PM, Arthur Kalmenson <arthur.k...@gmail.com>wrote:
> It doesn't, OOPHM is suppose to be scheduled for 2.0. It is possible
> to use OOPHM from the branch, although I haven't tried it myself.
> --
> Arthur Kalmenson
> On Sun, Feb 8, 2009 at 8:28 AM, Samyem Tuladhar <sam...@gmail.com> wrote:
> > Great! I was wondering if this version supports OOPHM?
> > Thanks,
> > Samyem
> > On Feb 6, 10:26 am, 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.
> >> 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
I am interested to migrate from the 1.5.3 to the 1.6.0 M1. When I use
this M1 with -war option, the the compiler output is not like an
expanded war. I tried to specify all parameters (-war, -gen, -
extra ..) without success. The output of the compiler is always
similar to the output of the 1.5.3 compiler. The compiler indicates
the 1.6.0 version, so I am sure to use the 1.6. I am under linux
(ubuntu).
Do you have any idea why the compiler output is not like an expanded
war ?
Regards,
Seb
On 6 fév, 16:26, Scott Blum <sco...@google.com> wrote:
> 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.
> 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.
> 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. If you run into a
> serious issue, feel free to also reply back to this thread.
> Happy coding,
> Scott, on behalf of the GWT team
I guess in the sample projects (included in the M1 build), there is
build file for each and every of them, and within that, there build
tasks for the project. Maybe, you can have a try what there?
On Feb 9, 2:49 am, Sebastien <chassa...@gmail.com> wrote:
> I am interested to migrate from the 1.5.3 to the 1.6.0 M1. When I use
> this M1 with -war option, the the compiler output is not like an
> expanded war. I tried to specify all parameters (-war, -gen, -
> extra ..) without success. The output of the compiler is always
> similar to the output of the 1.5.3 compiler. The compiler indicates
> the 1.6.0 version, so I am sure to use the 1.6. I am under linux
> (ubuntu).
> Do you have any idea why the compiler output is not like an expanded
> war ?
> Regards,
> Seb
> On 6 fév, 16:26, 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.
> > 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.
> > 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. If you run into a
> > serious issue, feel free to also reply back to this thread.
> > Happy coding,
> > Scott, on behalf of the GWT team
> 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. > Happy coding, > Scott, on behalf of the GWT team
Greetings:
Thanks for the tremendous efforts from GWT team and supporting communities. Here are some preliminary exploration and wish list of the coming doc:
1) Using the webAppCreator (ant 1.7.0, jdk 1.6) i create an application, run the hosted mode, then the build to compile the app. In the app war directory, i see the hosted.html and app.nocache.js, but Not the .css and .html file as listed in the compiler output of the StockWatcher 1.6 example.
2) The current gwt-incubator_1-5_Dec_28.jar is not compatible with GWT-1.6.0. Hope the new compatible version will be out soon. I am still working through the examples to understand the new war structure, especially the project that uses different modular GWT modules and the location of public files for different modules. Some documentation and suggested best practices may be required.
3) With new GWT Event Handler, the stockwatcher example shows a container class to use a single handler method for event (ClickHandler) coming from different event publishers (but1 and but2). GWT team may share its experience and approach for all GWT event types in 1 container class, especially the way to integrate GWT event handler with OpenAjax Hub, leveraging GWT JSO and coming UIBinder ;-)
4) In the doc Articles and Tutorials, i see GWT for JSON Mashups and Application of Facebook. It may be a good idea to centralize in 1 place possible GWT applications and how-to to leverage Google API and facilities: Gears, AppEngine, google-ajax-examples, etc.
I take a look on the build.xml of samples. I didn't see any special
difference.
Here is a part of my build.xml :
<java maxmemory="1200m" classname="com.google.gwt.dev.Compiler"
fork="true" failonerror="true" taskName="gwtc">
<arg value="com.raisepartner.prism.PRISM" />
<classpath>
<pathelement location="src/main"/>
<fileset dir="${prj.lib}"><include name="**/*.jar"/></fileset>
</classpath>
</java>
=====>
[gwtc] Compiling module com.raisepartner.prism.PRISM
[gwtc] Compiling 10
permutations
[gwtc] Permutation compile
succeeded
[gwtc] Linking into
war
[gwtc] Link
succeeded
[gwtc] Compilation succeeded --
483,002s
The output is 'war' directory at the root of my project. This
directory contains only the module directory. There is no WEB-INF
directory created. Is it the expected behavior ?
By looking the samples I understand that my main html page (the one
calling the nocache.js) must me copied manually at the root of the war
directory. The content of the <module>.public is copied into war/
<module>. I expected the content would be copied at the root of the
'war' directory.
So my conclusion is that there is no change compared to the
1.5.3 ... :-(
Regards,
Seb
On 8 fév, 23:45, Dop Sun <dop...@gmail.com> wrote:
> I guess in the sample projects (included in the M1 build), there is
> build file for each and every of them, and within that, there build
> tasks for the project. Maybe, you can have a try what there?
> On Feb 9, 2:49 am, Sebastien <chassa...@gmail.com> wrote:
> > Hi,
> > I am interested to migrate from the 1.5.3 to the 1.6.0 M1. When I use
> > this M1 with -war option, the the compiler output is not like an
> > expanded war. I tried to specify all parameters (-war, -gen, -
> > extra ..) without success. The output of the compiler is always
> > similar to the output of the 1.5.3 compiler. The compiler indicates
> > the 1.6.0 version, so I am sure to use the 1.6. I am under linux
> > (ubuntu).
> > Do you have any idea why the compiler output is not like an expanded
> > war ?
> > Regards,
> > Seb
> > On 6 fév, 16:26, 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.
> > > 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
"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)."
I'm not following... Do you mean for us to include these static
resources in the compiler output directory and maintain this directory
under source control (with generated code alongside static source,
such as index.html and css files)? That seems like a bad idea to me.
Why not enforce the standard J2EE project path (see Sun's blueprints),
and maintain these files under /src/conf.
On Sun, Feb 8, 2009 at 12:11 PM, Itamar Ravid <itamar.ira...@gmail.com>wrote:
> The difficulty arises when using Hosted Mode. First, I have to copy a > modified web.xml to ${project}/tomcat/webapps/ROOT. This web.xml routes all > requests to /services/* to my springDispatcher. This web.xml is different > than the one I distribute with my WAR, since it also includes mapping for > the GWTShellServlet. Also, in order for serialization to work, I have to > compile my project once (using GWTCompiler) and copy all resulting *.gwt.rpc > files to ${project}/tomcat/webapps/ROOT/${module}/. This occurs because the > GWTShellServlet generates these dynamically as GWT-RPC requests arrive.
> I've semi-automated the whole process using Ant tasks, and I'm aware of the > gwt-maven plugin which provides some of this functionality, but I'd like to > know whether the situation has been fully or partly addressed with the 1.6 > release.
Itamar,
I think you should find 1.6 much easier once you've switched over from GWTShell to HostedMode. Just use your real web.xml in hosted mode to map in your springDispatcher; you no longer need to use GWTShellServlet at all.
It's actually fairly compatible, the difference is more in attitude and
expectation. You would provide the WEB-INF directory yourself, GWT no
longer tries to control everything. The model is more that GWT can plug in
easily to existing web apps. For example, you would also want to setup
build rules to compile your server-side code into WEB-INF/classes.
On Mon, Feb 9, 2009 at 1:35 AM, Sebastien <chassa...@gmail.com> wrote:
> Hi,
> I take a look on the build.xml of samples. I didn't see any special
> difference.
> Here is a part of my build.xml :
> <java maxmemory="1200m" classname="com.google.gwt.dev.Compiler"
> fork="true" failonerror="true" taskName="gwtc">
> <arg value="com.raisepartner.prism.PRISM" />
> <classpath>
> <pathelement location="src/main"/>
> <fileset dir="${prj.lib}"><include
> name="**/*.jar"/></fileset>
> </classpath>
> </java>
> =====>
> [gwtc] Compiling module com.raisepartner.prism.PRISM
> [gwtc] Compiling 10
> permutations
> [gwtc] Permutation compile
> succeeded
> [gwtc] Linking into
> war
> [gwtc] Link
> succeeded
> [gwtc] Compilation succeeded --
> 483,002s
> The output is 'war' directory at the root of my project. This
> directory contains only the module directory. There is no WEB-INF
> directory created. Is it the expected behavior ?
> By looking the samples I understand that my main html page (the one
> calling the nocache.js) must me copied manually at the root of the war
> directory. The content of the <module>.public is copied into war/
> <module>. I expected the content would be copied at the root of the
> 'war' directory.
> So my conclusion is that there is no change compared to the
> 1.5.3 ... :-(
> Regards,
> Seb
> On 8 fév, 23:45, Dop Sun <dop...@gmail.com> wrote:
> > I guess in the sample projects (included in the M1 build), there is
> > build file for each and every of them, and within that, there build
> > tasks for the project. Maybe, you can have a try what there?
> > On Feb 9, 2:49 am, Sebastien <chassa...@gmail.com> wrote:
> > > Hi,
> > > I am interested to migrate from the 1.5.3 to the 1.6.0 M1. When I use
> > > this M1 with -war option, the the compiler output is not like an
> > > expanded war. I tried to specify all parameters (-war, -gen, -
> > > extra ..) without success. The output of the compiler is always
> > > similar to the output of the 1.5.3 compiler. The compiler indicates
> > > the 1.6.0 version, so I am sure to use the 1.6. I am under linux
> > > (ubuntu).
> > > Do you have any idea why the compiler output is not like an expanded
> > > war ?
> > > Regards,
> > > Seb
> > > On 6 fév, 16:26, 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.
> > > > 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
On Mon, Feb 9, 2009 at 9:47 AM, logicpeters <logicpet...@gmail.com> wrote:
> "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)."
> I'm not following... Do you mean for us to include these static > resources in the compiler output directory and maintain this directory > under source control (with generated code alongside static source, > such as index.html and css files)? That seems like a bad idea to me.
Not exactly... the compiler output directory is considered to be "/war/<moduleName>".... NOT "/war" itself really. In other words, you can put whatever resources you want into the top-level war directory, the compiler generated files will always be put into the moduleName subdirectory under this, so as not to conflict.
Why not enforce the standard J2EE project path (see Sun's blueprints),
On Mon, Feb 9, 2009 at 6:33 PM, Scott Blum <sco...@google.com> wrote:
> On Sun, Feb 8, 2009 at 12:11 PM, Itamar Ravid <itamar.ira...@gmail.com>wrote:
>> The difficulty arises when using Hosted Mode. First, I have to copy a
>> modified web.xml to ${project}/tomcat/webapps/ROOT. This web.xml routes all
>> requests to /services/* to my springDispatcher. This web.xml is different
>> than the one I distribute with my WAR, since it also includes mapping for
>> the GWTShellServlet. Also, in order for serialization to work, I have to
>> compile my project once (using GWTCompiler) and copy all resulting *.gwt.rpc
>> files to ${project}/tomcat/webapps/ROOT/${module}/. This occurs because the
>> GWTShellServlet generates these dynamically as GWT-RPC requests arrive.
>> I've semi-automated the whole process using Ant tasks, and I'm aware of
>> the gwt-maven plugin which provides some of this functionality, but I'd like
>> to know whether the situation has been fully or partly addressed with the
>> 1.6 release.
> Itamar,
> I think you should find 1.6 much easier once you've switched over from
> GWTShell to HostedMode. Just use your real web.xml in hosted mode to map in
> your springDispatcher; you no longer need to use GWTShellServlet at all.
from my point of view it is nice that GWT 1.6 brings a more
transparent project structure.
BUT, what we really need is a concept which fits into enterprise
development strategies.
e.g. I'm not able to see how using maven and continous integraton and
developing can be achievend in a painless way.
- running application in hosted mode maybe with an own server (-
noserver mode))
- working with more than one project
- clean seperation of generated and not generated code
- and so on...
Yes, I know it is possible to handle this stuff and we did it ... But
we spent already so much time on this infrastructural things. And I
guess we are not alone....
And to get a simple to use infrastructure is almost impossible.
I haven't yet played with the new project structure, but speaking with
1.4 and 1.5 experience, I agree with Martin - that it is somewhat
difficult to build GWT projects with "enterprise continuous
integration systems", such as Maven (which, in particular, depends on
a certain project structure). A little more configurability in where
source can be located may be the best solution to this issue.
On Feb 10, 4:01 am, maku <martin.k...@gmx.at> wrote:
> from my point of view it is nice that GWT 1.6 brings a more
> transparent project structure.
> BUT, what we really need is a concept which fits into enterprise
> development strategies.
> e.g. I'm not able to see how using maven and continous integraton and
> developing can be achievend in a painless way.
> - running application in hosted mode maybe with an own server (-
> noserver mode))
> - working with more than one project
> - clean seperation of generated and not generated code
> - and so on...
> Yes, I know it is possible to handle this stuff and we did it ... But
> we spent already so much time on this infrastructural things. And I
> guess we are not alone....
> And to get a simple to use infrastructure is almost impossible.
On Feb 6, 10:26 am, Scott Blum <sco...@google.com> wrote:
> 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.
Ooh. Does the inclusion of DatePicker imply that
ImmutableResourceBundle is also ready? I'm trying to get my head
around how styling works in DatePicker. It looks rather complex...
> 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.
We've rolled our own using this exact technique, to make a
LazyTabPanel, etc but this will be easy to retrofit. Great addition,
thanks!
> 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.
> 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.
> 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. If you run into a
> serious issue, feel free to also reply back to this thread.
> Happy coding,
> Scott, on behalf of the GWT team
On Feb 10, 11:45 pm, Mark Renouf <mark.ren...@gmail.com> wrote:
> On Feb 6, 10:26 am, Scott Blum <sco...@google.com> wrote:
> > 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.
> Ooh. Does the inclusion of DatePicker imply that
> ImmutableResourceBundle is also ready? I'm trying to get my head
> around how styling works in DatePicker. It looks rather complex...
To answer my own question, I just looked at the release branch and the
ImmutableResourceBundle/StyleInjector support was removed. It's got
the standard list of CSS class selectors in the Javadoc, and a set of
default styles has been added to the GWT theme css.
> Unfortunately, there's still nothing about Maven support. No official > repository, no official plugin.... I hope this will arrive this > Milestone 2.
> Regards, > Alexandre de Pellegrin
This is not likely for 1.6... we simply don't have any Maven users (much less experts) among the contributors. If this is something a lot of people would find valuable, it would be great if someone in the community could step up.
I will note that we made some changes in 1.6 regarding ClassLoaders that should remove barriers to running GWT hosted mode (and unit tests) from within Maven.
Well, I just finished changing every single listener i have into
handlers and have to rewrite widgets a little that fires listeners. I
have no idea what to do with the build.xml thing to make it using new
compiler.
On Feb 12, 9:26 am, Scott Blum <sco...@google.com> wrote:
> > Unfortunately, there's still nothing about Maven support. No official
> > repository, no official plugin.... I hope this will arrive this
> > Milestone 2.
> > Regards,
> > Alexandre de Pellegrin
> This is not likely for 1.6... we simply don't have any Maven users (much
> less experts) among the contributors. If this is something a lot of people
> would find valuable, it would be great if someone in the community could
> step up.
> I will note that we made some changes in 1.6 regarding ClassLoaders that
> should remove barriers to running GWT hosted mode (and unit tests) from
> within Maven.
> Unfortunately, there's still nothing about Maven support. No official
> repository, no official plugin.... I hope this will arrive this
> Milestone 2.
> Unfortunately, there's still nothing about Maven support. No official
> repository, no official plugin.... I hope this will arrive this
> Milestone 2.
> Regards,
> Alexandre de Pellegrin
> On Feb 6, 4:26 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.
>> 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.
>> 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. If you run into a
>> serious issue, feel free to also reply back to this thread.
>> Happy coding,
>> Scott, on behalf of the GWT team
GWT 1.6 M1 log.tld file not found error
Hi,
I was using GWT 1.5. Today I moved my application to GWT1.6M1 so as to
try the rich features. When I move the project I am getting below
error when I start my application.
Please note if I create some example application it works fine. Can
some one throw some light on the same.
Regards,
Allahbaksh
java.io.FileNotFoundException: C:\workspace\ProjectName\war\WEB-INF
\log.tld (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.getInputStream (Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity
(Unknown Source)
at
com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVers ion
(Unknown Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
(Unknown Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl
$JAXPSAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.mortbay.xml.XmlParser.parse(XmlParser.java:188)
at org.mortbay.xml.XmlParser.parse(XmlParser.java:204)
at
org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp
(TagLibConfiguration.java:227)
at org.mortbay.jetty.webapp.WebAppContext.startContext
(WebAppContext.java:1217)
at org.mortbay.jetty.handler.ContextHandler.doStart
(ContextHandler.java:513)
at org.mortbay.jetty.webapp.WebAppContext.doStart
(WebAppContext.java:
448)
at com.google.gwt.dev.shell.jetty.JettyLauncher
$WebAppContextWithReload.doStart(JettyLauncher.java:236)
at org.mortbay.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart
(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:39)
at com.google.gwt.dev.shell.jetty.JettyLauncher.start
(JettyLauncher.java:283)
at com.google.gwt.dev.HostedMode.doStartUpServer
(HostedMode.java:368)
at com.google.gwt.dev.HostedModeBase.startUp
(HostedModeBase.java:587)
at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:
394)
at com.google.gwt.dev.HostedMode.main(HostedMode.java:231)
On Feb 13, 8:26 pm, Scott Blum <sco...@google.com> wrote:
|
