> 1) Backwards compatibility. If we updated JUnitShell to use HostedMode, it > seems like old test cases would probably break. The idea of a > JUnitHostedMode is a good one... but how would we be able to tell which one > the user meant, since the JUnit framework is in control?
So does this mean that GWTTestCases still spawns off a headless hosted mode that's using an embedded Tomcat and not an embedded Jetty? -- Arthur Kalmenson On Thu, Feb 19, 2009 at 9:16 PM, Scott Blum <[email protected]> wrote: > To be honest, we kind of punted on a full JUnitShell port for a couple of > reasons: > 1) Backwards compatibility. If we updated JUnitShell to use HostedMode, it > seems like old test cases would probably break. The idea of a > JUnitHostedMode is a good one... but how would we be able to tell which one > the user meant, since the JUnit framework is in control? > 2) It should work okay for pure client-side testing. I take it from your > message that you're doing something more sophisticated, that involves > server-side code also? > > On Thu, Feb 19, 2009 at 4:15 AM, Netsurfer <[email protected]> wrote: >> >> Hi, >> I was using GWT 1.5 since some weeks ago, now I moved my application >> to GWT1.6M1 in order to use the new war structure with a Spring server >> application context. >> Everything works fine with HostedMode: this version simplifies a lot >> web frameworks integration. >> >> Now the problem: >> I want to test my application with GwtTestCase but it uses JUnitShell >> that extends GwtShell and there isn't any implementation like a >> JUnitHostedMode that use the new war structure or, more in general, >> the possibility to use HostedMode instead of GwtShell in a >> GwtTestCase. >> The consequence is that I'm not able to test my GWT Spring application >> because every file inside the new war structure isn't reachable on a >> GwtShell and the Spring context isn't loaded. >> >> Is there any solution? >> >> Thanks in advanced, >> Marco >> >> On 6 Feb, 16:26, Scott Blum <[email protected]> wrote: >> > Greetings GWT developers, >> > >> > The GWT team is happy to announce the availability of 1.6 Milestone 1! >> > Binary distributions are available for download directly from GWT's >> > Google >> > Code project. >> > >> > http://code.google.com/p/google-web-toolkit/downloads/list?can=1&q=1.6.0 >> > >> > As always, milestone builds like this are use-at-your-own-risk. There >> > are >> > known bugs, and it definitely isn't ready for production use. Please >> > expect >> > some trial and error getting everything to work. The javadoc that comes >> > bundled with the distribution should be up-to-date, but the online >> > Developer >> > Guide (http://code.google.com/docreader/#p=google-web-toolkit-doc-1-6) >> > is >> > still very much a work in progress. We will be updating it over the next >> > several weeks. In lieu of an up-to-date Developer Guide and release >> > notes, >> > below are the major highlights relative to GWT 1.5.3. >> > >> > *** New Project Structure in GWT 1.6 *** >> > >> > One of the biggest changes to GWT 1.6 is a new project structure. The >> > old >> > output format has been replaced by the standard Java web app expanded >> > "war" >> > format, and the actual directory name does default to "/war". Note that >> > the >> > war directory is not only for compiler output; it is also intended to >> > contain handwritten static resources that you want to be included in >> > your >> > webapp alongside GWT modules (that is, things you'd want to version >> > control). Please also note that the "GWTShell" and "GWTCompiler" tools >> > will >> > maintain their legacy behavior, but they have been deprecated in favor >> > of >> > new "HostedMode" and "Compiler" tools which use the new war output. When >> > 1.6 >> > is officially released, we will be encouraging existing projects to >> > update >> > to the new directory format and to use the new tools to take advantage >> > of >> > new features and for compatibility with future GWT releases. >> > >> > The sample projects provided in the GWT distribution provide an example >> > of >> > correct new project configurations. For more details on the specifics of >> > the >> > new project format, please see GWT 1.6 WAR design document >> > (http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6). >> > >> > A couple of important changes we should highlight here: >> > >> > - Projects with server-side code (GWT RPC) must configure a "web.xml" >> > file >> > at "/war/WEB-INF/web.xml". This web.xml file must define and publish any >> > servlets associated with the web application. See the included DynaTable >> > sample. Additionally, server-side library dependencies must be copied >> > into >> > "/war/WEB-INF/lib". For example, any GWT RPC servlets must have a copy >> > of >> > gwt-servlet.jar in this folder. >> > >> > - HTML host pages will no longer typically be located in a GWT module's >> > public path. Instead, we'll be recommending that people take advantage >> > of >> > the natural web app behavior for serving static files by placing host >> > pages >> > anywhere in the war structure that makes sense. For exmaple, you might >> > want >> > to load a GWT module from a JSP page located in the root of your web >> > app. To >> > keep such handwritten static files separate from those produced by the >> > GWT >> > compiler, the latter will be placed into module-specific subdirectories. >> > Any >> > page that wishes to include a GWT module can do so via a script tag by >> > referencing the GWT-produced "<module>.nocache.js script" within that >> > module's subdirectory. As of 1.6, we'll be recommending that only >> > module-specific resources used directly by GWT code, such as image files >> > needed by widgets, should remain on the public path. See the included >> > Showcase sample for some examples of this distinction. >> > >> > - When you do need to load resources from a module's public path, always >> > construct an absolute URL by prepending GWT.getModuleBaseURL(). For >> > example, >> > 'GWT.getModuleBaseURL() + "dir/file.ext"'. This advice has not changed, >> > but >> > in the past it was easy to be sloppy with this, because the host page >> > and >> > GWT module typically lived in the same directory, so using a relative >> > URL >> > would usually do the right thing. Now that GWT modules live in a >> > subdirectory, you must reference public resources through >> > GWT.getModuleBaseURL(). >> > >> > *** Hosted Mode Enhancements *** >> > >> > Although the legacy GWTShell still uses an embedded Tomcat server, the >> > new >> > HostedMode runs Jetty instead. There is also a new "Restart Server" >> > button >> > on the main hosted mode window. Clicking this button restarts the >> > internal >> > Jetty server, which allows Java code changes to take effect on the >> > server >> > without having to completely exit and restart hosted mode. This is >> > useful >> > when making code changes to RPC servlets, or when serializable RPC types >> > are >> > modified and the server and client are out of sync. >> > >> > *** New EventHandler System *** >> > >> > Event handlers have been added to replace the old event listeners used >> > by >> > Widgets, History, and various other classes. The new system has a few >> > differences from the old system: >> > >> > - EventHandler methods always take a single parameter: the GwtEvent that >> > the >> > Widget fired. For example, ClickHandler has a single method >> > onClick(ClickEvent). >> > >> > - Each GwtEvent contains accessors relevant to the event, such as the >> > key >> > that was pressed on KeyEvents. Native events provide access to the >> > underlying native event object. >> > >> > - Each EventHandler defines only one method, so you do not need to >> > create >> > empty methods just to satisfy the interface requirements. >> > >> > For users who create their own Widgets, you no longer need to manage >> > listeners manually. Every Widget has a HandlerManager that manages all >> > of >> > its handlers. For native events, such as ClickEvent, just call >> > addDomHandler() from within your code to register a handler and sink the >> > associated event on the Widget. When the native event is detected, the >> > handler will automatically be called. For logical events, such as >> > SelectionEvent, call addHandler() and fire the event manually using the >> > fireEvent() method. >> > >> > You can see examples of EventHandler usage in many of the updated GWT >> > widgets and samples, or in new projects created with the new >> > webAppCreator >> > tool. >> > >> > You can now trigger a native event on almost any Element. Create a new >> > native event using the Document.create*Event() methods, then dispatch it >> > on >> > a specific Element by calling Element.dispatchEvent(). These methods >> > allow >> > you to expand your test coverage in ways that were previously >> > impossible. >> > >> > *** New Widgets *** >> > >> > DatePicker >> > >> > The new DatePicker and DateBox widgets allow your users to select a date >> > from a calendar. The Showcase sample provides examples of both of these >> > widgets. >> > >> > LazyPanel >> > >> > The new LazyPanel widget allows you to delay the creation of certain >> > sections of your application until they are first accessed, improving >> > startup performance. For example, if your application has a seldom used >> > "Help" section, you can wrap it in a LazyPanel and create the user >> > interface >> > only if and when the user tries to access it. To use the LazyPanel, >> > extend >> > the class and override the abstract createWidget() method. The >> > createWidget() method will be called the first time you call >> > setVisible() on >> > the LazyPanel. >> > >> > *** Fixed Issues *** >> > >> > Please see our bug tracker for a full list of fixed issues and >> > enhancements >> > >> > (http://code.google.com/p/google-web-toolkit/issues/list?can=1&q=statu... >> > ). >> > >> > 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 >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
