Announcing Sencha GXT 3.0

Sencha GXT 3.0

We’re excited to announce the general availability of Sencha GXT 3.0! Sencha GXT, previously known as Ext GWT, is our popular Java based web application framework that leverages the Google Web Toolkit compiler. With Sencha GXT 3.0, developers can build high performance web applications with cross-browser compatibility across all desktop browsers.

Download Sencha GXT

Easier to Learn

This major release has given the GXT team a chance to take a step back and reconsider existing features and API design. We’ve made a number of breaking changes from Ext GWT to better support current GWT features and best practices, to make the library easier to use and theme, and to plan for future improvements both in GWT and GXT.

To make existing projects easier to upgrade, we’ve also ensured that Ext GWT 2 and GXT 3 can be run in the same project. Check out Running Version 2 and 3 together for more information.

GWT Events & Handlers

Ext GWT 2.0 had a custom event and listener API that was written before GWT released its Events & Handler API. With GXT 3.0, we have replaced this custom event system in favor of the built-in GWT Handler API. Now GXT components accept handlers and fire events in the same way as other GWT widgets. This makes adding event handler methods in uibinder-enabled projects easier, and removes the need to send some events through an EventBus and others through Observable objects. This change also makes it easier for a developer’s IDE to give them hints about events that can be fired, and assists users with autocomplete to quickly write strongly typed handlers for these events.

GWT Based Rendering

With Ext GWT 2.0, components rendered their DOM structure lazily. That is, the component’s DOM elements were not created when the component was constructed. This behavior differed from that of GWT Widgets, which create their DOM elements immediately. This difference managed to confuse some users, and required them to take special precautions in order not to access components that had not yet been created.

With GXT 3.0 we’re opting for the GWT model which means that there is consistent behavior when working with both GXT Components and GWT Widgets. This makes use of the widgets more predictable, as there is no need to be certain that some calls are only made pre- or post-render.

Strongly Typed Layout Engine

GXT 3.0 introduces strongly typed layout containers. This is in contrast to Ext GWT 2.0, where a generic layout container could be given any layout. Because the container was generic and not strongly typed, it was possible to use the API incorrectly. For example, in 2.0, it was possible to use the wrong type of layout data for a given layout. With 3.0, the API now forces the correct use of layout data for each container type.

Full UiBinder Support

GWT 2.0 introduced the ability to construct user interfaces in a declarative way using XML files. To support UiBinder in Widgets, several conventions had to be followed. These included implementing HasWidgets to allow a Widget to behave as a container, implementing HasHTML to allow raw HTML directly in panels, and adding @UiConstructor and @UiChild annotations in widgets to support custom behavior.

Ext GWT 2 was released prior to GWT 2.0 and thus did not have support for UiBinder. UiBinder support has been one of the major driving factors for many of the API changes in Sencha GXT 3.

GXT 3 has a library to make it easier to create complex layouts in UiBinder files. These changes have been accepted by the GWT team for their upcoming 2.5 release, and in the meantime, are available in the uibinder-bridge jar, available as part of the GXT 3 download.

For a more detailed look, see our Learn article about Declarative Markup with UiBinder in Sencha GXT 3.

<gxt:FramedPanel collapsible="true" headingText="Example" pixelSize="100, 80">
  <button:TextButton ui:field="exampleButton" text="Click Me" />

UiBinder example result

Core Improvements

Improved Model Support

In Ext GWT 2, several model object interfaces and base classes were provided, such as ModelData, TreeModel, BaseModelData. These types allowed for a species of pseudo-reflection by making each model responsible for tracking the mapping from a String key to the referred property. This could make it difficult to use existing POJO beans and to write code in a type-safe way. It also made it difficult to effectively use AutoBeans and RequestFactory.

GXT 3 now supports any bean-like object, with public accessors (getters and setters) through its XTemplates. PropertyAccess also provides a mechanism to generate ValueProvider instances. ValueProvider handles changing and reading values from outside the models in a generic way.

With these changes, users have the flexibility to use their own domain objects without being required to use GXT model classes or implement GXT model interfaces.

Data Loading, Reading, & Writing

The Store classes continue to be the basis for client-side data management in GXT 3. Loaders, DataProxys, and Readers are still the ideal way to provide the data for Stores. As in 2.0, there is no requirement to use them – data can be added directly to the stores. However, we’ve greatly improved their generics and made it easier to send data to and from the server in a variety of ways. For those who choose to take advantage of these classes, the GXT 3.0 data classes are a huge improvement in developer convenience and productivity.

Ext GWT 2.0 used the introspection-like features of ModelData to allow access to data within an object. With GXT 3.0, ValueProvider instances can be used to generically refer to individual nested properties, and GWT’s AutoBean functionality can be used to turn bean interfaces into data loaded to and from the server. The HttpProxy and ScriptTagProxy classes can both generate XML or JSON for the objects sent to the server. Alternatively, they can also generate simple URL-encoded data. Furthermore, readers can easily map JSON properties or simple XML x-paths to bean properties.

Loaders and Proxies now use specific generics to avoid confusion about the type of model or data that is expected from or that will be produced by any particular object. This avoids many common problems, such as class cast exceptions, that occur when less stringent typing is used. These additional type parameters can make object declarations more verbose, but also more precise. These changes result in better static code checking from your IDE or compiler. The Explorer demo shows how to turn both XML and JSON into trees or lists to be consumed by their appropriate Stores.

For additional information, see our introduction to Data in our blog post for Developer Preview 1.

Interface Based Design

Projects using GXT often work with large, complex user interfaces, and to keep these projects easy to maintain and test it is important to separate discrete units of functionality. In this way, any unit can be tested or replaced without greatly affecting other units. GXT 3 makes it easier to mock and replace the components and event sources by implementing meaningful interfaces wherever possible. For many events, we implement a HasHandlers interface from GWT, such as for HasSelectionHandlers on components that allow logical selection of data, whereas for others such as the Stores, we provide our own events and handler interfaces to accurately describe what is happening in each case.

In some instances where GWT provides interfaces for events that seem reasonable, we avoid using them in favor of more comprehensive events. For example, TextButton implements HasSelectHandlers rather than HasClickHandlers, because buttons can be selected through the mouse or keyboard. If handlers were only added for ClickEvents, a user interface could miss keyboard selection of their forms.

Where possible, we declare many GXT 3 classes in a shared package, indicating that this code does not require being run in GWT, though it is designed for it. Stores and Loaders are two examples of this – they do not require actual GWT support so presenter classes that use them can be tested on a JVM instead of the much slower GWTTestCase.

Compile Time Templates

XTemplates are a powerful feature in GXT 3.0. Prior to 3.0, XTemplates were implemented using the same design and code as Ext JS. For 3.0, we decided to replace this JavaScript-based implementation with a solution better fitting GWT and the features it offers.

The new XTemplate design uses GWT Deferred Binding to process a template and generate GWT-optimizable Java to retrieve the data from any Java Bean. Data can be read from any Java Bean, ClientBundle or CssResources to make theming elements easier. Furthermore, there is no need to “convert” the data to a JavaScriptObject. The new design supports virtually all of the old XTemplate features and functionality, and now can be better optimized by the compiler.

In summary, the new XTemplate design is a much improved design over the previous XTemplate. We are leveraging GWT Deferred Binding to provide a GWT like solution.

interface TemplateTest extends XTemplates {
  SafeHtml renderStock(StockProxy stock);
  SafeHtml renderStockExternal(StockProxy stock);

For additional information, see our XTemplate blog post.

New Features

Cell Enhancements

GWT 2.1 introduced the Cell API, a sort of ‘Widget Lite’ mechanism to allow large numbers of elements to be rendered efficiently. These were often wrapped in a widget of some kind, yielding “high-performance, lightweight widgets composed of Cells for displaying data.” See this guide for background information on cells.

Cells use the flyweight pattern to use a single object to render many elements, and to handle incoming events for all of them in a consistent way. Many fields and other components in GXT 3 are implemented first in Cells, then wrapped in a Cell widget, allowing them to be drawn cheaply in a grid, or used as a field in a form, with the same basic features available in either case.

All GXT 3 data components support using Cells to draw their content, including ListView, Tree, Grid, and TreeGrid. (In contrast, Ext GWT 2 used either a GridCellRenderer to put together HTML content or a widget drawn in each cell, resulting in simple content, or very heavy grid elements). By using Cells instead, GXT 3 supports the best of both worlds, providing a solution to handle any high-performance interactive content. Take a look at the Cell Grid example. Fields can still be created as an editor for a column, allowing grid cells to alternate between rendered data and editable content, as in Ext GWT 2. Check out our examples of inline grid editing and row grid editing for details.

Cell grid

Custom Theming and Appearances

GXT 3 components and cells are responsible only for handling events and managing the data they are given. In Ext GWT 2, they also drew their html elements and css class names, resulting in components that could be difficult to modify, extend, and restyle. Through the use of the GWT Appearance pattern, we have factored out this content and style, and it is now easy to re-theme any widget, or all widgets of the same type in an application.

By using XTemplates and ClientBundles, we further ensure that elements are rendered from strings, not manipulated DOM elements, and that only the CSS and images which are presently being used are loaded into the DOM.

For additional information, see our Appearance blog post.

Plugin-free Charting

One of the most exciting new features of GXT 3 is the brand new, plug-in free, charting package. Built on web technologies (SVG and VML), the new charting package is a write-once, run-anywhere solution that doesn’t have third party dependencies. It works on every browser down to IE6, and because it’s all written in GXT it’s completely customizable and very easy to extend.

We’ve created pie charts, lines charts, area charts, radar charts and more — all animated, all easy to configure and all very extensible. We’ve included 23 charting and drawing examples for this release that show off many of the configurations available to you.

Area chart

For additional information, see our Charting blog post.

Maven Support

As with our beta and release candidates, GXT 3.0.0 is available through maven central as well as through a downloadable zip. The groupId and artifactId are unchanged, and the new version is 3.0.0:


The version in Maven Central is covered under GPLv3, and we’re now hosting our own repository for commercially licensed artifacts.

  <name>Sencha commercial releases</name>

Please note that full Maven support for both GPL and Commercial will be available within a week of the Sencha GXT 3.0 release. Please subscribe to the forum post to get notified when full Maven support is available.

The GXT 3.x Roadmap

Sencha GXT 3.0 lays the groundwork for the next generation of web application frameworks. We are planning to add support for the Gray theme, and following that, we plan to introduce RTL and ARIA support.

Again, we thank the community for your bug reports, questions, and suggestions which have helped us in delivering this release. Sencha GXT 3 is a major advancement in the product line and we hope you enjoy using it.

Download Sencha GXT