Thursday, September 18th, 2008

Ext GWT 1.1 Released

Category: GWT, Sencha

<p>

Darrell Meyer has announced the release of Ext GWT 1.1 which is said to “shortens the feature set gap between Ext JS.”

New Features

The Grid component wraps the Ext JS grid, and it includes support for grid plugins which fit into component lifecycles. You can also use a subclass, EditableGrid which…. allows you to edit content on the fly.

Auto complete has been added to the combo boxes a la Google Suggest.

Portal is a custom layout container that uses a multi-column layout on contains Portlets. Each Porlet can be drag and dropped to change order or move to another column. Each Portlet can contain any content and supports icons to expand / collapse, close, etc.

The desktop mimics the behavior of the operating system look at feel. It is now possible to create multi-window applications with support for a task bar and start menu. Windows support normal, maximize, and minimize states. The start menu is a custom menu that allows new menu items. In addition, there is support for a “task” area for adding additional items.

Java Bean Support with BeanModel

The Ext GWT Store and Binder API work with ModelData instances. The primary goal of ModelData is to provide a type of “introspection” as GWT does not allow runtime inspection of Java objects. You can query ModelData for a list of properties it contains, and these properties can be retrieved and set using the parameter name with the get and set methods.

Although this approach works, it forces you to either implement the ModelData interface in your Java Beans or extend the Ext GWT base classes that implement the ModelData interface. What is missing is a way to use your Java Beans as is, without having to extend the Ext GWT base classes or implement an “invasive” interface.

There are also new examples:

  • Forum search is an example of a combo box, using a custom XTemplate, and remote data. The data can be paged with built-in support for a paging toolbar.
  • Image Chooser shows loading a ListView in a Window. Each item has a linked details view, and the ListView supports custom sorting and filtering.
  • This example shows a Dialog using an AnchorLayout to “anchor” the form fields to the dialog dimensions. When resized, the fields will adjust their size to match the dimensions of the dialog.

Related Content:

Posted by Dion Almaer at 7:25 am
15 Comments

++++-
4.3 rating from 64 votes

15 Comments »

Comments feed TrackBack URI

I don’t really understand the value of recreating the Ext JavaScript API in Java? Statically typed Java ends up creating 2-3 times the volume of coding required to do what is done via Javascript. Is it because J2EE developers don’t want to learn JavaScript??

Comment by simongil — September 18, 2008

At the very least you get the GWT compiler optimizations.
.
You also get access to other GWT libraries, such as Gears, Search, Maps and so on.
.
You also get the java development environment and IDE support. This means that while it may take 2-3 times more statically typed *code*, it doesn’t require 2-3x as much *coding*. Much of it is generated/auto-completed by an IDE.

Comment by abickford — September 18, 2008

@simongil
There’s a “gazillion” reasons to doing just that. Though I am a “believer” in server-side Ajax as you can see by following my link…
But I’ll toss in a few reasons;
* Many developers *don’t* know JavaScript, many developers *do* know Java
* You get (most of) your code to run in a protected environment behind the firewall in your server which increases the level of security
* You get to use the compiler which will trap most of the bugs you’d normally have to have JS Unit Tests for (which BTW is a nightmare to build)
* You get far less browser portability problems since the ExtJS team (or we) do this for you
* Probably your app will be more responsive (though with GWT I am not 100% sure) since the amount of JavaScript often gets orders of magnitudes smaller
* You can incorporate all the optimalizations (like GZipping of JS files, minification, adding script tags to the bottom of the page and so on) in the LIBRARY meaning this is no longer a “choice” but the *default* behavior which again increases the level of responsiveness of your apps
* No more Cross Site XHR problems since you fetch the data from other services/servers from your own server instead of within the client (yes I know you can build a proxy, but with ExtGWT and other “sibling projects” this is *implicit*)
* You can get to use a “gazillion” other libraries like (j/n)Unit, (n)Hibernate, log4(Net/Java) and so on without having to create JS abstractions on top of them
* You get the Java/.Net IDEs with intellisense, refactoring and all the other goodies
.
Practically JS development is like assembly programming 40 years ago, necessary but decreasingly important the more Ajax matures…
The future belongs to abstracting away JS and anyone who bets different are in for a though ride. I thinks the Ext team’s focus on GWT is VERY mature and foresighted… ;)
.
But these are MY thoughts and I might be wrong ;)

Comment by ThomasHansen — September 18, 2008

@ThomasHansen
“Practically JS development is like assembly programming 40 years ago, necessary but decreasingly important the more Ajax matures…
The future belongs to abstracting away JS and anyone who bets different are in for a though ride.”

I think you are completely wrong here. Javascript is getting more features, a lot faster, broader adoption. Jaxer even takes it to the server, which is probably not yet mature enough, but definitely something I’m sure will be improved. I think Javascript will be a language which you will see more often in desktop applications because of things like gears and AIR. There are more and more developers learning the language, more books written about it.

Summary: I think it will be the complete opposite of what you said. Not abstracting away JS, but more and more usage of JS.

Comment by Tommy Maintz — September 18, 2008

Wow…those two comments sure don’t help a person pick which direction to go when learning this stuff. :)

I’m learning Ext JS right now…but am wondering if I should be learning Java and going the GWT direction instead.

Comment by Jonny — September 18, 2008

The thing I hate about GWT is that it takes 40sec of building just to see weather your your element looks better with an icon on it or not… Otherwise, GWT doesn’t suck much.

Comment by mare — September 18, 2008

@Jonny
Learn BOTH, you need JS knowledge for another 30 years just like you needed ASM knowledge the first 30 years of computer development, but rely as much as possible on Java ;)

Comment by ThomasHansen — September 18, 2008

One thing I don’t understand: why is there still no proper keyboard support in Ext? Or is it simply unused in the demos? The demos I’ve seen show a glaring lack of support within seconds of using, especially the ‘desktop’ demo.

And Ext-JS isn’t the only widget library with this (seemingly, correct me if I’m wrong) fault, most out there don’t capture keypresses properly (as the native OS version of those controls do). It makes for a frustrating experience whenever such widgets are used.

Comment by DiSiLLUSiON — September 19, 2008

@DiSiLLUSiON – mostly keyboard events just aren’t demonstrated that much. Ext does provide good support though:

http://extjs.com/deploy/dev/docs/?class=Ext.KeyMap
and
http://extjs.com/deploy/dev/docs/?class=Ext.KeyNav

Comment by danh2000 — September 19, 2008

I see, so they have it… but hardly use it in their own widgets? That’s a shame.

It does illustrate my point: Even the tree in the documentation browser isn’t easy to navigate using the keyboard; typing a word to scroll to a certain topic, using arrow keys to expand/contract a branch or using page up/down to quickly browse through the list simply doesn’t work.

After paying such amount of attention to their top-notch widgets (everything is pixel-perfect and, as far as I can determine, cross-browser), it does seem strange such basic functionality isn’t included by default.

I do hope the next release will take care of that, the widgets aren’t really usable in a productive online application as-is.

Comment by DiSiLLUSiON — September 19, 2008

@DiSiLLUSiO
I don’t know about all the other frameworks, but Ra-Ajax (ours) is stuffed with support for Keyboard Shortcuts (if that’s what you mean)
Check out e.g.; http://ra-ajax.org/samples/Effects.aspx
and try the Keyboard Shortcuts there which is attached with the buttons the…
(Though it’s pure .Net/Mono so probably not that interesting for Java people)
(And also quite IMmature (0.4 release, 0.5 coming up within a week))

Comment by ThomasHansen — September 19, 2008

Yes, but that’s not what I mean. Those buttons simply implement accesskey. What I mean is, for example, your Tab control. In graphic OS environments (Windows, and I believe Linux as well), the Tab control can also be directed with the keyboard, when it has focus. Try it on a native Tab control on your OS. Use the arrow keys to move forward/backward. Use pgup/pgdown/home/end keys to move to the start or the end of the list. In your example, it doesn’t work. It doesn’t have to be much work, but it’s (imo) very important for any heavy duty user of whatever software uses your widgets. Of course, there are widgets out there which use keys differently in the same context on different OS’es, but a combination or even part of an implementation is better then no implementation at all.

Comment by DiSiLLUSiON — September 19, 2008

How would GWT work in a single page app? AFAIK, you can code up a “page” in Java (I can’t see why not to use Javascript directly – just GET THE SKILLS), but then do you have to reload a new page each time with the associated reload of the javascript?

Comment by ExtAnimal — September 20, 2008

I think mare pretty much summed it up with “The thing I hate about GWT is that it takes 40sec of building just to see weather your your element looks better with an icon on it or not…”. UI design is extremely iterative. You might do 200 iterations a day as you build and tweak a layout. At 40 seconds, these GWT iterations add up to a lot of wasted time.
.
My take is abstracting away from the very platform (html/javascript) that we deploy to just doesn’t make sense. It’s like wanting to drive a race car, but sitting in the back and telling a driver what to do. Might sound good in theory, but you’ll never get the best out of the vehicle. So learn JavaScript, and reap the benefits from being in the drivers seat.
.
As for GWT-Ext, the power is in Ext. Leverage that with it’s native JavaScript API. Don’t step back and get bogged down with a Java bridge to that API. And the API is one thing, but the UI mechanics are another. Consider a maintenance UI with a dozen different field types (radio sets/combo boxes/text fields), multiple widgets within (grids/trees/whatever) and with inter-dependencies between all of them. Add read/write/delete functionality where you’ve got to enable/disable certain fields&widgets as part of it. Now JavaScript as dynamically typed makes it a breeze to hook all these components together and create some slick routines that step through all UI objects and apply enable/disable/RO/RW automatically. Try and do that with Java, and watch the lines of code pile up. Worse still, you’ll probably end up writing a dozen different state routines with 20 enable commands handling each UI component individually.
.
There is real power in JavaScript. Why avoid it?

Comment by simongil — September 22, 2008

And, isn’t it argument enough that even with this latest release, the api still lags behind what ext-js 2.2 offers?

Comment by simongil — September 22, 2008

Leave a comment

You must be logged in to post a comment.