The Ext GWT team has been hard at work on Ext GWT 3.0 and we’re happy to announce the availability of Ext GWT 3.0 PR5. This will be the last developer preview release as we move toward our 3.0 beta releases. There are a tremendous number of improvements and features added since PR4. As a result, we are closing in on being feature complete.
Now is a great time to grab the SDK and to get familiar with the API. All major changes to the public API are complete so this release is a good representation of how the final API will work. As with any developer preview release, keep in mind there are still bugs, missing features, and rendering issues, some of which may pop up as you explore the API.
### Module Separation
With previous versions of Ext GWT there is a single monolithic module. With 3.0, we have separated the library into a number of smaller, more logical modules. This provides more fine-grained control of what features of the library you want to use.
The core modules include:
* **Core:** com.sencha.gxt.core.Core
* **Cell Components:** com.sencha.gxt.cell.Core
* **Data and Binding:** com.sencha.gxt.data.Data
* **Drag and Drop:** com.sencha.gxt.dnd.DND
* **Effects and Animations:** com.sencha.gxt.fx.Fx
* **Localized Messages:** com.sencha.gxt.messages.Messages
* **State:** com.sencha.gxt.state.State
* **Base Theme:** com.sencha.gxt.theme.Base
* **Blue Theme:** com.sencha.gxt.theme.Blue
* **Complete Framework:** com.sencha.gxt.ui.GXT
* **Components:** com.sencha.gxt.widget.Core
As before, all core modules can be included by inheriting com.sencha.gxt.ui.GXT in your application’s module, as the GXT module will inherit each other modules, as well as combine permuatations and set certain default settings.
### GWT Widget Support
In previous releases of Ext GWT, Components are not rendered the same way as GWT Widgets. Components are rendered “lazily” meaning their DOM elements are not created until they are actually needed. With GWT Widgets, the DOM elements are created when the widgets are constructed. Because of this difference, you would use Components and GWT Widgets differently. With 3.0, Components are not rendered lazily and work the same was as GWT Widgets.
Furthermore, prior to 3.0, Ext GWT Containers worked only with Components. Any non-components would need to be wrapped in a component wrapper. With 3.0, containers work with Widgets directly and no wrapping is required.
Because of the two changes mentioned above, it is much easier and feasible to maintain consistent behavior when using GWT Widgets in Ext GWT Containers and using Ext GWT Components in GWT Panels.
### Appearance Pattern and Themes
We’ve removed the need for external CSS and images in Ext GWT 3.0. If you’ve used Ext GWT before, you’re familiar with the resources folder – a folder of static images and CSS files used by the library. In the past, setting up a new Ext GWT project would involve copying this folder into your project and linking the gxt-all.css style sheet.
In 3.0, we’ve implemented the GWT [Appearance](http://code.google.com/p/google-web-toolkit/wiki/CellBackedWIdgets#Appearance_Pattern) pattern and now take full advantage of ClientBundle and CssResource. There is no longer a need to reference the gxt-all.css and the associated images. All CSS and images are contained within the library source code and module public folder. Also for Maven users, the Ext GWT jar now includes both the Java source code and style resources (CSS and images). There is no longer a resources jar, just the single Ext GWT jar.
The only requirement for theming is to add a reference to reset.css in your application’s host page. reset.css is a small CSS file that clears the default (and browser-specific) padding and margins from most HTML elements. Here’s the host page for the Explorer demo:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>Ext GWT Explorer Demo - ${build.description}</title> <link rel="stylesheet" type="text/css" href="explorer/reset.css" /> </head> <body> <script language='javascript' src='explorer/explorer.nocache.js'></script> <iframe src="javascript:''" id="__gwt_historyFrame" style="position:absolute;width:0;height:0;border:0"></iframe> </body> </html>
Also note the first line – the HTML document type declaration. Ext GWT 3.0 works only in strict mode, which is activated in browsers when an appropriate declaration is placed at the beginning of the document. The [HTML5 doctype](http://dev.w3.org/html5/spec/Overview.html#the-doctype) can also be used to trigger strict mode:
<!DOCTYPE html>For more information about the Appearance pattern, see this [blog article](https://www.sencha.com/blog/ext-gwt-3-appearance-design/).
### UiBinder Support
GWT 2.0 release introduced the ability to construct user interfaces declaratively using XML templates. To allow for composing widgets in UiBinder, there are several conventions to which to adhere. These include using the HasWidgets interface 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 facilitate custom behavior.
Ext GWT 2 was released prior to GWT 2.0 and did not have any support for UiBinder. Compatibility between Ext GWT 3.0 and UiBinder has been one of the major driving factors for many of the API changes in Ext GWT 3.0.
Here’s a very simple example of a UiBinder template containing Ext GWT 3.0 components:
<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder" xmlns:gxt="urn:import:com.sencha.gxt.widget.core.client" xmlns:button="urn:import:com.sencha.gxt.widget.core.client.button"> <gxt:FramedPanel collapsible="true" headingText="Example" pixelSize="100, 80"> <button:TextButton ui:field="exampleButton" text="Click Me" /> </gxt:FramedPanel> </ui:UiBinder>
For more information on using UiBinder with Ext GWT, see this
### Charts
This release includes many new features in the chart framework. There is now a greater level of customization available to developers who use Ext GWT charts. Some of the main points of customization include the use of series renderers and label providers.
[](https://www.sencha.com/examples-dev/#ExamplePlace:columnrendererchart “Column Renderer”) [](https://www.sencha.com/examples-dev/#ExamplePlace:scatterrendererchart “Scatter Renderer”)All series provide labeling of their data points. Labels provide a more precise interpretation of the data on the chart.
[](https://www.sencha.com/examples-dev/#ExamplePlace:barrendererchart “Bar Renderer”)There is also now event support in charts. Try clicking the pie slices in this chart.
[](https://www.sencha.com/examples-dev/#ExamplePlace:pierendererchart “Pie Renderer”)Using the time axis, it is easy to visualize data values by date. This example shows data being updated continuously, much like what you’d see in a live monitoring application.
[](https://www.sencha.com/examples-dev/#ExamplePlace:livechart “Live Chart”)The new draw examples show the underlying sprite framework on which the Ext GWT 3.0 charts are built. Be sure to try resizing the logos to see the dynamic nature of vector graphics.
[](https://www.sencha.com/examples-dev/#ExamplePlace:basicdraw “Basic Draw”) [](https://www.sencha.com/examples-dev/#ExamplePlace:logos “Sencha Logo”)### Cells and Cell Widgets
Cells are a fairly new design pattern and implementation by GWT. “Cell widgets (data presentation widgets) are high-performance, lightweight widgets composed of Cells for displaying data.” See this [guide](http://code.google.com/webtoolkit/doc/latest/DevGuideUiCellWidgets.html) for background information on cells.
With this release we have added support for cells in all our data widgets, including: Grid, ListView, Tree and TreeGrid.
In previous versions of Ext GWT, it was possible to add widgets to data components. Although this functioned properly, performance was quite slow. This is because there is a large overhead in creating and adding widgets to data components. For each row, a new widget instance is created.
In the cell pattern, a single Cell instance renders each row’s value (be it a number, a button, or a date picker) in the column. In addition, cells do not listen for events directly. Instead, they are passed to the cell from its container.
Here’s an example of a custom Cell that listens for click events:
SimpleSafeHtmlCell<String> cell = new SimpleSafeHtmlCell<String>(SimpleSafeHtmlRenderer.getInstance(), "click") { @Override public void onBrowserEvent(Context context, Element parent, String value, NativeEvent event, ValueUpdater<String> valueUpdater) { super.onBrowserEvent(context, parent, value, event, valueUpdater); if ("click".equals(event.getType())) { Info.display("Click", "You clicked "" + value + ""!"); } } };
### Field Cells
Most field components in 3.0 are cell based. This means that you can easily use a field cell such as a TextInputCell in a data widget like a grid. You can also use these cells individually by using the corresponding component. For example, to use a TextInputCell as a component, use the included TextField. The component works together with the cell to provide a cohesive component that works like any other GWT component including working with the GWT event system.
We’ve also applied the appearance pattern to our cells. With these changes, it’s now possible to have interactive behavior in our data widgets by using cells. More importantly, this behavior is possible without the overhead and performance problems of working with widgets.
Our cells require some changes in order for them to work properly in our editors and cell based data widgets. At this time the cells are not fully functioning. These changes will be in place before the beta release.
### Data Loading and Writer
The Store classes continue to be the basis for client-side data management in Ext GWT, and Loaders, DataProxys, and Readers are still an 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 the generics on them 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 the convenience of using these classes, the Ext GWT 3.0 data classes are a huge improvement in developer convenience and productivity.
Previously, Ext GWT used the introspection-like features of ModelData to allow access to the data within an object. With 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 and from data loaded from the server. The HttpProxy and ScriptTagProxy classes can both be asked to generated XML or JSON for the objects sent to the server. Alternatively, they can also generate simple url-encoded data. Furthermore, readers are available to 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 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 and will point out the error instead of waiting for someone to use every single service. The Explorer demo shows how to turn both XML and JSON into trees or lists to be consumed by their appropriate Stores.
### New Examples
We have added several new examples to the Explorer Demo since PR4. These include:
* **Charts:** ToolTip Chart
* **Combos:** Advanced ComboBox
* **Drag & Drop:** Grid to Grid, List to List, Tree to Tree, TreeGrid to TreeGrid
* **Draw:** Basic Draw, Logos
* **Forms:** DualListField, FileUpload
* **Grid:** Aggregation, Cell, Basic, Grouping, Json, Live Grid, Paging, Xml
* **Layouts:** AccordionLayout, Center Layout,, HtmlLayout, PortalLayout
* **Template & Lists:** DateCell ListView
* **ToolBar & Menu:** Advanced ToolBar, MenuBar, Overflow ToolBar, Status ToolBar
* **Tree:** Cell Action Tree, Fast Tree, Filter Tree
* **TreeGrid:** Async TreeGrid, Basic TreeGrid, Editable TreeGrid
* **Window:** Accordion Window
These examples can be viewed at here.
### External Links
Here is a list of previously released content about 3.0. Some of the code samples may be using API’s that have changed since the content was published. Make sure to take a look at the examples in the current release for current and proper API usage.
* [Appearance Design](https://www.sencha.com/blog/ext-gwt-3-appearance-design/)
* [Drawing & Charting](https://www.sencha.com/blog/ext-gwt-3-drawing-and-charting/)
* [Declarative Markup with UiBinder](https://www.sencha.com/learn/ext-gwt-3-declarative-markup-with-uibinder/)
* [Template Redesign](https://www.sencha.com/blog/ext-gwt-3-xtemplate-redesign/)
### What’s Missing
There are a handful of features / components that are not in this preview release. These include:
* Grid row expander, Grid row numberer, Grid filtering, Grouping summary view
* Grid column reordering
* RowEditor
* CheckBox selection model
* TimeField
* Tri-state Tree and TreeGrid
* Desktop and Mail demo
* Gray theme
### What’s Next
The team is working on adding the missing features. In addition, we have handed over the code to our QA team and started more robust testing. We will release the first beta release once we are feature complete which should be fairly soon.
We are also working on documentation for 3.0. This includes cleaning up and adding new content to JavaDocs. In addition, we are working on an manual for 3.0.
We are looking forward to presenting Ext GWT 3.0 at our upcoming conference. We will cover the various features and changes in 3.0 in more detail.
### Nightly Build
We have setup a nightly build and deployment of the Explorer demo. This is a good place to see the latest code running in the demo. See:
(http://staging.sencha.com:8080/examples-dev)### Maven
The final release of 3.0 will be put into Maven central and no extra repository is required. However, the releases before GA are released as snapshot releases.
To get the [snapshot releases](https://oss.sonatype.org/content/repositories/snapshots/com/sencha/gxt/), you will need to add the following repository section to your pom.xml:
<repository> <id>sonatype-snapshots</id> <name>Sonatype Snapshots</name> <url>https://oss.sonatype.org/content/repositories/snapshots/</url> <snapshots> <enabled>true</enabled> </snapshots> </repository>
We have several artifacts available:
* **gxt-release** – A zip of the release, similar to how Ext GWT was released before 3.0
* **gxt** – The core component and data classes
* **gxt-charts** – The new drawing and charting API
* **gxt-legacy** – Classes to ease porting projects from earlier Ext GWT versions
* **uibinder-bridge** – Optional support to allow complete configuring non Widget types using <ui:with> in UiBinder XML. Will not be required when Google releases 2.5
### Summary
Thanks for reading this article and for trying Ext GWT 3.0 PR5. We’re very excited about Ext GWT 3.0, and we hope this release will show you the potential of this next major update to Ext GWT.
Also please visit the Explorer Demo. Release notes for PR5 are here.
What's your reaction?
0
0
gxt 3.0 will support form like extjs4 (http://dev.sencha.com/deploy/ext-4.0.2a/examples/form/contact-form.html)?
great job!
Wonderful news! I have been waiting to see this, and you guys managed to deliver as usual. Thank you so much, downloading :)
Is there an announced GA date for Ext Gwt 3.0 ? Q4 2011 ? Q1 2012 ?
So cool… Grid, RF, UiBinder! Can’t wait for the final version. Thank you guys.
This is excellent. Does GXT 3.x support mobile devices (gestures, themes, etc..)?
@Bill
Yes, it had to be out at the end of the summer. 2 month overdue and yet another DP version. Epic fail gxt team. ty so much, I switched to pure gwt. bye bye
@raivis
Such a negative post on a very positive news. I am not giving excuses, but if you have done any serious development, you would have been much more tolerant to those deadlines.
@Bill We are targeting early 2012 for the GA 3.0 release.
@Robert La Ferla At this time, 3.0 does not support mobile gestures.
@raivis I can understand your frustration with the delivery dates of 3.0. GWT is a moving target, and we are trying to keep Ext GWT as powerful as possible, using the latest concepts from GWT for as long as possible. Two changes that we originally did not scope for were Appearances and Cells, which we felt were important to implement. Supporting Cells required us to rewrite most of our fields and data widgets. Implementing the Appearance pattern required us to rewrite most of our existing CSS, HTML, and images. These are changes the community has requested and are consistent with the direction of GWT. We will have a beta release out before end of year which will be feature complete with a stable API.
@Darrell Meyer Thanks. I used GXT 2.x to develop some rather large sites like Xilinx Semiconductor’s software licensing center, Allscripts and Misys Banking. I think what you guys have done is amazing. The GXT platform is an excellent one and 3.0 is a big step towards minimizing the pain associated with the gain. I strongly urge you to make mobile support (gestures/themes/etc..) the next critical feature post 3.0 and implement it as quickly as you can. I have been experimenting with Sencha Touch and it pains me to code directly in Javascript. I looked at nextinterfaces.com and if they were more feature complete, I’d dump Sencha Touch. However, if GXT 3.1 had Android/iPhone support, that would be best.
Looks excellent. Downloading! Also looking forward to final version release. :) Cheers.
Great news!
@Alain You make a good point about us being in silence mode. Going forward we will make sure to keep the community better informed of current development status and release dates.
RegExValidator seems to be broken. No email validator.
ToolTip is awful class. It doesn’t provide convenient methods for title and body change. And doesn’t work with standard GWT textfields.
But all other improvements are awesome. Thank you, Darrell.
What version of GWT will DP5 work best with?
great work on the new release. just one thing – it might help to be specific about what dependencies gxt 3.0 has. it took me a few hours to realize that a runtime compilation error i was getting was caused by not including gwt-user.jar (not a dependency for gxt 2.5)
Darren,
Wonderful Job I did not go through the details but as a developer and being in this field for 14+ my 2 cents at a high level or bird’s eye view:
1>All modules Can be inherited by inheriting com.sencha.gxt.ui.GXT. I feel this will become Readability problem. Detail like full names and avoiding no standard acronyms have always made life not easy but tough. They have Street names with no meaning if we had meaningful street names I would have navigated without maps ?
3>sencha [com.sencha.] in the API names. Were we not taught in the school of Magic [Harry Potter?] not to name things after such Proper Nouns will sencha always Remain sencha? Later it might be oracle sencha or IBM sencha who knows also one word less in each file.
I would have gone for
a)com.gxt.shared.event instead of com.sencha.gxt.core.shared.event
b) All widgets have a core just eliminate the core and leave it as com..gxt.widget.client.treegrid instead of com.sencha.gxt.widget.core.client.treegrid
In nutshell sencha and core ? avoidable and unnecessary clutter eliminate them will make it clean 2 years down the line you may add another 2 periods already on 6 now. Which you can make it to 4 by removing core and sencha
4>on reset.css, what if we have some apps which need a override and include some proprietary things don’t make anything strict we need to be flexi, nothing strict has worked.
We all reach the same cross roads after all we are Homo sapiens somewhere we share a common gene ? . I have gone through the above when I write my simple classes and simple programs ?
Apolgogies for the Repost the above one was copied from word doc so lots of ? instead of :) pl ignore above post and consider this one here…
Darrell,
Wonderful Job I did not go through the details but as a developer and being in this field for 14+ my 2 cents at a high level or bird’s eye view:
1>All modules Can be inherited by inheriting com.sencha.gxt.ui.GXT. I feel this will become Readability problem. Detail like full names and having non standard acronyms has always made life not easy but tough. They have Street names with no meaning if we had meaningful street names I would have navigated without maps :)
3>sencha [com.sencha.] in the API names. Were we not taught in the school of Magic [Harry Potter:)] not to name things after such Proper Nouns will sencha always Remain sencha? Later it might be oracle sencha or IBM sencha who knows also one word less in each file.
I would have gone for
a)com.gxt.shared.event instead of com.sencha.gxt.core.shared.event
b) All widgets have a core just eliminate the core and leave it as com..gxt.widget.client.treegrid instead of com.sencha.gxt.widget.core.client.treegrid
In nutshell sencha and core :) avoidable and unnecessary clutter, eliminating them will make it clean. 2 years down the line you may add another 2 periods already on 6 now. Which you can make it to 4 by removing core and sencha
4>On reset.css, what if we have some apps which need a override and include some proprietary things don’t make anything strict we need to be flexi, nothing strict has worked.
We all reach the same cross roads after all we are Homo sapiens somewhere we share a common gene :) . I have gone through the above when I write my simple classes and simple programs :)
Hi there, I just ported my projects to use GXT 3.0.0 DP5. I had some troubles but I managed to rewrite everything (including the extensive use of ModelData). I am very happy with the performance but also the clean API. I must agree with Ani/ani786, some choices seem a bit strange on behalf of readability.
Very nice job Sencha !!
You decide on the indication for the generator through inheritance, ex:
interface FooBeanProperties extends PropertyAccess
How will it look like when the bean extends other ? Ex:
class FooBean extends BarBean ?
It seems that annotaion indication could be better. Ex:
@PropertyAccess(FooBean.class)
interface FooBeanProperties extends BarBeanProperties
Darrell,
Once again u r doing a wonderful job….
I read some of the above posts and the delays in GXT some ranting , we need all of that :).
I understand the delay was due to dependency on GWT and their releases….
my 2 cents again…
Y dont we create a Shield[layer] around the GXT , to ensure such changes done by the mother framework or another child framework have minimum impact we just modify that layer.
Otherwise this is going to become a nightmare as we grow, and other frameworks take a different path , that way GXT can concentrate on what best it can do by itself rather than the lookups and assumptions,ther will be no end to this route.
I wite what i observe with my own eyes s i am an implementer not a hoax architect who just talk the crap ….The Roads about US is what i loved they plannned it quite quite ahead the space and the width where as other countries keep reworking on the same rather than other progress :)
Regards
Ani
I’ve been testing this release for quite a while now and I think it really excellent. I wasn’t a very experienced GWT developer when I started the testing, but I’ve still managed to make an text application which looks quite good and behaves quite nicely.
One question … I haven’t seen a password text box. Is there someplace and I’ve just overlooked it?
It’s missing. There is a boolean password but it is not (yet) used.