Ext GWT 3.0 Developer Preview 1

The Ext GWT team has been hard at work on our Ext GWT 3.0 release. We are happy to announce the availability of our first developer preview release. 3.0 is a major upgrade from 2.0 with a massive amount of changes and updates. One of the primary goals of 3.0 is the bring Ext GWT more inline with the current GWT best practices and designs. The release is not yet feature complete and we’re still under active development on the framework. This release provides a great opportunity for developers to see how the release is shaping up, previewing what 3.0 will look like and get to see how the API looks.

Our plan is to push out new preview releases quite often. Until we reach beta, the current code and public API will change. Once we have the API stable and all features are complete we will go to beta.

Download Ext GWT 3.0 Developer Preview 1

At present, Ext GWT 3.0 requires at least GWT 2.3.0 to run, in order to take advantage of SafeHtml, UiBinder, AutoBeans, as well as other recent features. Following GWT’s deprecation of Java 1.5, Ext GWT also requires at least Java 1.6 to compile. One other book-keeping change to note: we have changed the package structure from com.extjs.gxt to com.sencha.gxt. In addition to reflecting the change the company has undergone in the last year, this may also aid efforts to update projects to use the new features in 3.0, as both old and new JARs can co-exist on the same classpath.

Events and Their Handlers

In Ext GWT 2.0, we had a custom event and listener API, which could be used in several ways:

Button btn = new Button();
    btn.addListener(Events.Select, new Listener<ButtonEvent>() {
        public void handleEvent(ButtonEvent be) {
        //respond to click
    }
});

or

btn.addSelectionListener(new SelectionListener<ButtonEvent>() {
    @Override
    public void componentSelected(ButtonEvent ce) {
        //respond to click
    }
})

With 3.0 we have replaced our custom event system in favor of the built-in GWT Handler API. Now the Ext GWT Components accept handlers and fire events in the same way as other GWT widgets.

Button btn = new Button();
btn.addHandler(new SelectHandler() {
    @Override
    public void onSelect(SelectEvent event) {
        //respond to click
    }
}, SelectEvent.getType());

or

btn.addSelectHandler(new SelectHandler() {
    @Override
    public void onSelect(SelectEvent event) {
        //respond to click
    }
});

This will make 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.

XTemplates

XTemplates are a powerful feature in Ext GWT. In previous releases, XTemplates were implemented using the same design and code as Ext JS. For 3.0, we have replaced the Ext JS JavaScript-based implementation with a compiled solution completely implemented in Java, in the same style as SafeHtmlTemplates.

interface TemplateTest extends XTemplates {
    @XTemplate("<div><span>{stock.name}</span></div>")
    SafeHtml renderStock(StockProxy stock);
 
    @XTemplate(source="template.html")
    SafeHtml renderStockExternal(StockProxy stock);
}

For more detailed information on XTemplates in Ext GWT see our previous blog post.

Charting

For 3.0, we’ve introduced a completely new drawing and charting API. Like we did in Ext JS, we’re moving away from Flash to pure web standards, and the new APIs replace our Flash-based charting solution from 2.0. The new code uses SVG and VML rather than using any plugins.

Ext GWT 3.0 draws gorgeous charts using SVG, Canvas and VML ? with no need for any plugins. The charting system is integrated with the new data package and fully animated in every browser.

Themes & Appearance

Currently in Ext GWT 2.0, widgets are responsible for creating their DOM structure directly. This is done either by manually creating the elements or by using an HTML fragment. The HTML for the widget is created from strings, from an XTemplate, or by assembling DOM elements. The CSS class names are then applied to the elements by the widgets. With this approach, a widget’s view is tightly bound to the widget itself and CSS class names are generally hardcoded into the widget.

Although this approach works, there are a few limitations. First, it is very difficult to change the DOM structure of a component as the widget is tightly bound to its current DOM structure. Second, it is also difficult to change the style or look and feel of a widget as the CSS styles are part of the widget, and added directly to the widget’s elements.

With Ext GWT 3.0, we have introduced a new way of rendering the view and styling a widget. This approach is very flexible and has many advantages compared to the previous method. It supports swapping in different DOM structures with different styles.

The design revolves around a concept called an Appearance which is based on a new design introduced by Google. An Appearance is simply a class that controls the HTML structure and style of a view implementation for a widget. An Appearance is a design pattern, rather than a concrete implementation. We have written an in-depth article on Ext GWT 3.0 Appearance Design for the latest Sencha newsletter.

Data

GWT does not support introspection at runtime: Given an object, you are not able to get and set values in a generic way. There are essentially two ways to deal with this: store all sub-properties in a generic way, or provide a mechanism that has access to getters and setters.

The first approach closely approximates how JavaScript and other dynamic languages work: the target object implements a known interface that allows values to be retrieved and set. This is the approach we took with Ext GWT with the ModelData interface.

public interface ModelData {
    <X> X get(String property);
    Map<String, Object> getProperties();
    Collection<String> getPropertyNames();
    <X> X remove(String property);
    <X> X set(String property, X value);
}

Ext GWT also provides a set of default implementations of the various model interfaces. To meet the requirements of the interface, the data stored within theses classes is stored in a map of values keyed by property name. Although this approach works, it forces users to adapt their data to the model interface or to use the Ext GWT base classes. While this provides excellent runtime access to all properties, it can cause larger code sizes, and makes the compiler’s job more difficult in deciding what code is not necessary.

The second approach is to use GWT Deferred Binding to generate code at compile time that knows how to “talk” to a given object. In earlier releases, this was accomplished through the BeanModel API, allowing Model instances to be created from regular Java Beans. Essentially, all the generic get and set calls are delegated to the wrapped Java Bean. Bean models would be created for every type that might need them, allowing the same level of reflection as ModelData provided, but again with greater code sizes, as the compiler would not always remove code that was not required.

For Ext GWT 3.0 we decided that we wanted to “rethink” the use of our Models and ?nd a cleaner solution. The goal of 3.0 is to support any bean-like object with get and set methods (POJO) or AutoBean (a new GWT feature) anywhere we require data in the framework. This includes our loaders, stores, data widgets, and templates. Similar to BeanModel, these methods to access properties are built at compile time, but are only created when requested by GWT.create, instead of aggressively loading data about all bean-like objects, letting the same code work with anything resembling a bean.

Properties are handled as ValueProvider, where T is the bean type and V is the type of the property. ValueProviders are designed to support both getters and setters, but can be generated in cases where only one or the other exists ? where the property is either read-only or write-only.

Other data can be retrieved in this way as well, such as keys for models, used to track objects in a Store. Extending the GWT ProvidesKey interface, we have a ModelKeyProvider type, able to specify a unique key for a given object of type T.

These providers can be generated together, as part of a PropertyAccess type. These are declared in the same way that XTemplates or Messages ? the interface is extended, and named methods are provided.

public class Person {
    public String getSSN() {...}
    public String getName() {...}
    public void setName(String name) {...}
    public List<Person> getChildren(){...}
    public void setChildren(List<Person>children) {...}
}
public interface PersonProperties extends PropertyAccess<Person> {
    ModelKeyProvider<Person> ssn();
    ValueProvider<Person, String> name();
    ValueProvider<Person, List<Person>> children();
}

As these will often be used to allow programmatic access to editing models, we have adopted some basic annotations and approaches from the GWT Editor framework. The name of each method is assumed to map to a property in the bean, and if two objects, say a ModelKeyProvider and a ValueProvider both need access to the same property, the @Path annotation may be used to specify the property instead. As in the Editor framework, the value of the path may include ?.’ to indicate further sub properties.

PropertyAccess objects can be useful to generate simple LabelProviders for ListView or ComboBox, or for interacting with a Store to queue changes that should not immediately take place. In other places, such as XTemplates or data widgets (which are still being developed), they will be generated automatically, working from cues the developer gives in code.

Legacy

We know many of these changes may make updating existing applications difficult. To ease those efforts, we have a separate JAR with classes that approximate behaviors available in 2.x, but like the rest of the 3.0 release, these are under the new package structure com.sencha.gxt. This will hopefully ease porting efforts, as the two sets of classes can co-exist.

The legacy JAR currently contains the basic ModelData interface and a ValueProvider implementation that can easily allow Stores and Data Widgets to read and write those objects without the need for PropertyAccess implementations. The Javascript-based XTemplate can also be found there, building Strings instead of SafeHtml.

Preview Notes and Gotchas

Since it’s just a preview, not all example are working at 100%. In addition, the current code has not been fully tested in all browsers and operating system. This holds true especially for Internet Explorer. We will be posting the 3.0 Explorer Demo in our next preview release. Of course by our final release we’ll be fixing all of these issues.

Also, for the first preview, we are asking for users to hold off on reporting bugs. If you have design comments or questions feel free to ask them in our 3.0 forums.

Next Drop

With 3.0, we are upgrading the layout engine for better performance and to support UIBinder. The new code is not in this drop but will be included in Dev Preview 2.

We have also started the work on implementing the Appearance design as described earlier. We are in the process of completing this work, and will also soon implement the Gray theme. While in this transition phase, we will have both our old resources (gxt-all.css) and our new resources contained within our theme modules.

Future Drops

There are several widgets and features not included in the release. This includes: Grid, TreeGrid, Fields, and others. These will be included in future releases.

Summary

We are excited about the preview of Ext GWT 3.0 and hope you will be as well. As a reminder, this is the first developer preview and is not ready for prime time. We would recommend using these previews to get a feel of the changes and to get an idea of how we are looking forward. We would not recommend starting to use the library at this time for any actual development.

Download Ext GWT 3.0 Developer Preview 1 today.