Sencha Inc. | HTML5 Apps

Blog

Ext GWT 3.0 Developer Preview 1

June 16, 2011 | Darrell Meyer

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.

There are 44 responses. Add yours.

Shaoning Zeng

3 years ago

Looks cool!

raivis

3 years ago

Finally smile)))) Downloading and trying out now

Krzysztof

3 years ago

Finally smile
No we are waiting for Dev 2 Preview with UiBinder support smile

Alain

3 years ago

There you go. now you guyz deserve some bravos smile
Looking really promising

Patrick Santana

3 years ago

Looking forward for this major release.

Matze

3 years ago

Can you provide more details regarding the planed timeline for the beta and the final release.

raivis

3 years ago

About the BaseModel and ModelData

Suppose I have a business desktop like application with many windows. By many I mean several hundreds of them.

with GXT v2.x I could make one model class and one base window and generate all of the windows i needed

If I am right from what I have read so far, you suggest to use severa; hundreds of model classes with implemented gettes and setters and also several hundreds of interfaces?

Rogério Valente

3 years ago

I download and try it.
My chalenge here is show a line chart and provide an option do save chart as image.
I copied the source of Linechart example and want to implement this feature.

Any sugestions?
Thanks in advance.

Colin Alworth

3 years ago

@Raivis There is no reason you cannot continue to use models as Map<String, Objects>, with lots of properties keyed to strings. Included in the legacy jar is the ModelData interface, and we will be including the base classes that implement it as well. While some new features, such as GWT’s editor framework or the compile-time XTemplates will not work correctly with runtime models, the v2 XTemplate is also included in the legacy jar, so run-time templates can still be used.

Alain

3 years ago

@Rogerio
I dont think that s supported

Rogério Valente

3 years ago

@Alan
Thanks for your reply.
I’ve been searching on the web for any solution to save a widget as an image without success.
Anyway, I’ll keeping looking.

Darrell Meyer

3 years ago

@Rogerio @Alain is correct. Saving charts to images is not supported.

Alain

3 years ago

@Rogerio
Unfortunatly GXT 3.xxx will also be a big problem for us because we will no be able to export the charts. In most of our applications users are generating reports and we were able to export the charts(Flash based ) to PD, PNG, JPG, etc,,, on the client. With the new release i dont know how we will do that. I might have to write a custom chart extenstion for GXT based on flash once i get my head around how GXT 3 works.

If you are working with GXT2.xxx i will soon release a solution that enables saving charts to different formats.
Check a demo here : http://gwt4air.googlecode.com/svn/trunk/exporter/GwtAir.html

Brendan Coughran

3 years ago

@Rogerio @Alain For the SVG engine you can save the DOM of the chart surface to a .svg file, which in turn can be converted to PDF, PNG, JPG, etc…

Alain

3 years ago

@Brendan
I m Aware of that. But there are some problems with that approach

1) Not cross browser
2) Cant be done on the client

So not suitable for us.

Sam

3 years ago

I hope the charts will support events & tooltips in the coming releases. Any plan of supporting stacked bars?

Henry P

3 years ago

@alain Have you looked at phantomjs?  Allows you to run a headless webkit on the server.  create pdfs, images, etc.

Alain

3 years ago

@Henry
We dont want to hit there server for that.
It has to be done on the client for us. That s why phantomjs is also not an option.

Ariya

3 years ago

@Alain: You can run PhantomJS on the client-side, there are executables for Windows, Mac OS X, and Linux. But if you want pure in-browser solution, then PhantomJS is not for you.

Rogério Valente

3 years ago

Hi @Brendan,

Do you have an implementation of that solution?

Alain

3 years ago

@Ariya, @Henry
We will go with Flash for now. Easier for us to integrate with GXT 2.xxx
For 3.xxx we will see how to do that if we ever switch.

Rogério Valente

3 years ago

@Alain

I’m trying to implement “save as image locally” in a gwt project but it’s not working fine.
Any tips?

thanks in advance.

Alain

3 years ago

@Rogerio
Are you using GXT 2.xxx or 3.xx ?
If you are using 2.xxx i might have a solution for you.

Rogério Valente

3 years ago

@Alain

I’m using GXT 2.xxx.
I downloaded the 3.xx only to test.

I’ll apreciate if you could share your solution.

Alain

3 years ago

Allright. I will bring our solution in a form where i can share that with you then i ll give you the code.
This might take one day or two dough. I hope this is ok for you.

Rogério Valente

3 years ago

@Alain,

that will be a great help.
Thank you very much.

Brendan Coughran

3 years ago

@Sam
Yes we plan to implement all the things you mentioned.

Alain

3 years ago

@Rogerio
Plase hav a loot at : http://gwt4air.googlecode.com/svn/trunk/exporter/GwtAir.html
and let me know if that s what you are looking for. If yes i ll be able to provide you the code tomorrow of the day after tomorrow

Rogério Valente

3 years ago

@Alain
Yes Alain. That will be a great feature on my project.
I’ll wait your message.

Thanks man.

lily

3 years ago

the whole life have to learn endless,although now i cannt understand what you introduce,i believe i will get it in the future

Alain

3 years ago

@Lily
Was your comment for me ?
If yes what it is that you dont understand ?  I just introduced a way to save GXT Chart on the client(no server and no executable)

@Rogerio
Do you have an E-Mail where i can reach you ?

Robert La Ferla

3 years ago

What’s the timeframe for the DP2 release?  I am anxious try UIBinder with GXT 3.  Also, why not rename Ext GWT to GXT for 3.0 once and for all?

Robert La Ferla

3 years ago

And I forgot to say that this is very very cool!  I guess the multiple column sort in Grid is taking a backseat for the time being or is that still in the release?

Rogerio Valente

3 years ago

@Alain,

Hi Alain, please send message to rogerio[dot]valente[at]gmail[dot]com

Thanks man.

Sebastien Tardif

3 years ago

It’s interesting to see that this support Canvas, quote: “Ext GWT 3.0 draws gorgeous charts using SVG, Canvas and VML”

In preview release of Ext JS 4, Canvas was supported then just before release, Canvas code was removed.

Brendan Coughran

3 years ago

@Sebastien
Actually that is a misprint. Currently only SVG and VML are supported. We may eventually add a Canvas engine.

raivis

3 years ago

@Colin Alworth
Yes, I understand there’s a legacy package. But for how long will it be supported by GXT? I am afraid that after some versions of GXT I will have to rewrite my one Data class and one generator class to hundreds of new data classes and generator classes.

Colin Alworth

3 years ago

@raivis
Take a look at the source of the ValueProvider instance that can read into a ModelData - it can be easily adapted to work with anything backed by Map<String, Object>. The legacy jar is made to work with the current Ext GWT api, which is not likely to change with respect to data models soon.

While this change is annoying to work with, closing this door has opened many others. Without this change, support for RequestFactory or AutoBeans are effectively impossible, and by making this change, we no longer need to support the BeanModel generation, but can use this more efficient method of reading properties without needing this psuedo-reflection to get access to arbitrary runtime methods.

Drop by #extgwt on freenode or file a ticket if you’d like to discuss this more - perhaps we’ve missed an important usecase or maybe we can explain better the direction we are headed.

Piotr Kosmowski

3 years ago

Finally. Can’t wait to see what your new child can do smile

raivis

3 years ago

@Colin Alworth
I’ll wait until some data widgets will be available and see how to code tabular data view. I’ll fill ticket if I will still have questions after that.

William Bonawentura

3 years ago

Would PropertyAccess still be implemented Observable pattern (like ChangeEventSource with Model)?

Colin Alworth

3 years ago

@William Bonawentura
We don’t yet have such an API for this, as that was mainly consumed by the Bindings code, which is being replaced by GWT’s own editor framework. Such an interface can be defined again, but without the Map<String,?> backing of the models, getting a reference to the property that was changed would be tricky.

This opens the doors to using AutoBeans and RequestFactory, not to mention standard java beans. It is also worth pointing out that GWT’s editor framework isn’t based on an observer pattern, but flow-synchronization instead.

Adrien

3 years ago

@Alain

Im interested in your “save localy” solution.
I’ll apreciate if you could share your solution

Thanks smile


Adrien

Hansjörg Oppermann

3 years ago

Why does the Maven paragraph was removed from the article? Maven is now no longer supported?

Comments are Gravatar enabled. Your email address will not be shown.

Commenting is not available in this channel entry.