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.
Table of Contents
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
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
These providers can be generated together, as part of a PropertyAccess
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.
Looks cool!
Finally :))))) Downloading and trying out now
Finally :)
No we are waiting for Dev 2 Preview with UiBinder support :)
There you go. now you guyz deserve some bravos :)
Looking really promising
Looking forward for this major release.
Can you provide more details regarding the planed timeline for the beta and the final release.
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?
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.
@Raivis There is no reason you cannot continue to use models as Map, 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.
@Rogerio
I dont think that s supported
@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.
@Rogerio @Alain is correct. Saving charts to images is not supported.
@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
@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…
@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.
I hope the charts will support events & tooltips in the coming releases. Any plan of supporting stacked bars?
@alain Have you looked at phantomjs? Allows you to run a headless webkit on the server. create pdfs, images, etc.
@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.
@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.
Hi @Brendan,
Do you have an implementation of that solution?
@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.
@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.
@Rogerio
Are you using GXT 2.xxx or 3.xx ?
If you are using 2.xxx i might have a solution for you.
@Alain
I’m using GXT 2.xxx.
I downloaded the 3.xx only to test.
I’ll apreciate if you could share your solution.
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.
@Alain,
that will be a great help.
Thank you very much.
@Sam
Yes we plan to implement all the things you mentioned.
@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
@Alain
Yes Alain. That will be a great feature on my project.
I’ll wait your message.
Thanks man.
the whole life have to learn endless,although now i cannt understand what you introduce,i believe i will get it in the future
@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 ?
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?
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?
@Alain,
Hi Alain, please send message to rogerio[dot]valente[at]gmail[dot]com
Thanks man.
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.
@Sebastien
Actually that is a misprint. Currently only SVG and VML are supported. We may eventually add a Canvas engine.
@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.
@raivis. 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.
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
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.
Finally. Can’t wait to see what your new child can do :)
@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.
Would PropertyAccess still be implemented Observable pattern (like ChangeEventSource with Model)?
@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
@Alain
Im interested in your “save localy” solution.
I’ll apreciate if you could share your solution
Thanks :)
Adrien
Why does the Maven paragraph was removed from the article? Maven is now no longer supported?