Darrell Meyer has announced Ext GWT 1.0. This is the first fully stable release of the product and it includes a lot of goodies including:
Documentation: new screencasts of the various steps
GWT 1.5 support: “Ext GWT is a 100% native GWT application written in Java. Ext GWT does not wrap any 3rd party JavaScript and does not use any external JavaScript files. Ext GWT fully leverages the GWT API including the widget lifecylce, events, listeners, messaging, and RPC.”
“Performance was a high priority item for the Ext GWT 1.0 release. Many changes were made since the first beta releases. Initial rendering times are quicker and the new layout code reacts quicker to window resizing. Improvements can easily be seen in the Explorer demo.”
Advanced Form Layouts
Improved Data Loading, Store, Binder, and Field API
Looks like a very solid release indeed. Congrats to the team.
Alex Moffat has written up an exploration of GWT linkers. It looks at the linking part of the GWT compilation step using as an example a linker that creates a sort of manifest for the JavaScript files created by compilation so that you can easily tell which file goes with which browser/locale/etc. combination.
In GWT 1.5 the build process is internally divided into two phases, compilation, which creates JavaScript from Java, and linking, which takes the JavaScript and other resources produced by the compilation phase and packages it for deployment. I wanted to understand a bit more about the linking process after seeing Bob Vawter talk about Resource Bundles and Linkers in GWT at the Google I/O conference. To try and help me do that I’ve created a linker that you can include in you build process to create a sort of manifest file listing which generated JavaScript file applies to which permutation of browser, locale etc.
To create a linker and have it called during the build process you need to do four things
Create a class that implements com.google.gwt.core.ext.Linker
Add a LinkerOrder annotation to the class to define whether the linker should run before the primary linker, after the primary linker or instead of the primary linker. You’re allowed as many linkers before and after the primary as you like but only one primary linker.
Define and add the linker in a <module>.gwt.xml file.
Include the new class in the classpath when running the gwt compiler.
The 1.5 RC1 build provides three different primary linkers that produce three different ways of packaging the compiler output for loading by the browser. The standard linker produces the familiar <module>.nocache.js file that loads the correct <strong name>.cache.html for the target browser. This is the linker that is added in Core.gwt.xml and so is the default linker that is used. Also provided are a cross site linker that creates a <module>-xs.nocache.js and a single script linker. You use the cross site linker if you need to host the GWT generated artifacts on a separate domain from your main site, for example if you use www.mysite.com for serving dynamic content and put all the static stuff, including JavaScript, on static.mysite.com. The single script linker can be used when the compilation process always creates a single JavaScript file that is applicable to all permutations.
Some good stuff came out from my employer. First, we have the Gears 0.3 release which includes support for Firefox 3! I have been using it for awhile, and it has been great. The team wanted to get it out before the Firefox 3 launch (planned for June 17th). A plugin like Gears can get deep into browser internals, so it is a challenge to keep up to date as APIs change in beta releases, so it is great to be out there now and I we will take a close look at the final release!
GWT 1.5 has a new release candidate. The 1.5 release is a big one, especially as it includes Java 5 language support!
Since the previous release of GWT, we’ve seen a lot of really great applications that demonstrate what is possible when you are able to focus on the user and stop worrying so much about browser quirks and other Ajax obstacles. Inspired by what we have seen so far, we have continued to concentrate our efforts on enabling developers to use their existing tools to create web apps that users enjoy. GWT 1.5 takes this commitment even further with exciting new features and over 150 bug fixes. And, like all GWT releases, most of the benefits are just an upgrade-and-recompile away.
I have been playing with the 1.5 trunk for awhile, and it has been a pleasure. What other major features does it have?
New compiler optimizations increase performance
With this release of GWT, we’re happy to announce that our compiler produces faster code than you would write by hand! How’s that? A bunch of new compiler optimizations allow us to efficiently inline method calls, even through many layers of indirection. Translation: all the nice abstractions and clean design work that are essential to maintaining a large code base melt away in the compiler’s output, giving your users the fastest possible experience. By contrast, if you were writing JavaScript by hand, you’d have to choose between writing good code and writing fast code — and when your application got to a certain size, maintainability would make the second choice impossible. With GWT 1.5, you don’t have to compromise; just write good code and let the compiler make it fast.
JavaScript Overlay Types
This further enhances GWT’s interoperability with the underlying JavaScript layer. “Overlay type†is a new term we’re using to describe the ability to model JavaScript objects as strongly-typed Java instances with no additional runtime cost. Overlay types make it easy to provide fine-grained interop with handwritten JavaScript libraries as well as providing an optimal way to make JSON structures directly accessible to GWT code.
High-performance DOM API
Up until GWT 1.5, we’ve concentrated mostly on Widget-level APIs, and until the advent of overlay types (above), direct DOM programming wasn’t particularly convenient. GWT 1.5 goes beyond “convenient” and well into “elegant” with an entirely new DOM API that enables type-safe, low-level DOM programming that will be both comfortable to DOM experts and free of any runtime overhead.
Default visual themes
Several default visual themes are now available by default so that developers get an attractive UI out of the box and have a good starting point to create their own custom styles in CSS.
We have seen some great talks on GWT at Google I/O, which should show up online in the near future (I will get them posted as soon as I can). For now, give 1.5 a try.
OpenKM is a multi-platform application for document management based on GWT, JBoss, and Jackrabbit (the content repository API).
Version 2.0 has been released, which you can test drive to see the application-style interface. The new features in 2.0 include: the previsualization of multimedia elements as images and videos, an improved an rewritten administration interface, a centralized management of templates, an exclusive area to allow users to store their private documentation, a tool for massive import and output data from ZIP files, searches by date ranks as well as translations to more languages.
However, one of the more relevant functions to mention is the indexing of the most common types of files: text, Office, Office 2007, OpenOffice, PDF, HTML, XML, MP3, JPEG, etc.
Today we have Bruce Johnson of the GWT team talking to us about GWT 1.5. He discusses the new features, such as the long awaited Java 5 language support, performance improvements, and much more.
It is very nice to take an application, run it through the new GWT 1.5 compiler, and get an instantly faster running application “for free”.
XSketch is “a multiplayer word sketch game. It is programmed in Adobe Flash, Java, Ajax, and GWT. Gameplay is similar to Pictionary where you sketch a picture with the goal of having other players guess your word and vice versa.”
Ryan Dewsbury creator this game, which he adds to his collection of GPokr and KDice.
One part of the Ext JS 2.1 release was the prominence of the sub project Ext GWT, a project that lets you code in Java with GWT while using the Ext components and framework.
But wait a minute, I thought that that project was GWT-Ext? Or wasn’t there something called MyGWT too? Confused?
Didier Girard has come to the rescue. He has discussed the different projects, how Ext GWT (the new one) is actually a repurposing of MyGWT. He also lists the differences, in his opinion, between the two projects (noting that the latest one is going to be rev’ing quickly):
Bob Lee is a co-worker of mine at Google (He is actually the lead on core Java APIs for Android), and he happened to create a cool little GWT application called Twubble, which he explains:
If you use Twitter, Twubble can look at your existing friends’ friends and recommend new people for you to follow. It’s a stupid simple idea, but I think the execution and fun factor have won people over.
I wrote Twubble in a couple nights of hacking in bed after the kid went to sleep. I used the latest Google Web Toolkit milestone which supports Java 5 (flawlessly from my experience). I was writing Javascript code (server and client side) for years before I ever got into Java, but I have to say, you’d be crazy to write AJAX apps any other way than GWT nowadays.
This is Bob’s first GWT application, so I wanted to sit down and talk to him about why he built the application, his experience with GWT, how he integrated with Twitter, and any other nuggets of information that I could get out of him:
Are you a fan of GWT but would like toms jQuery magic mixed in? Ray Cromwell has your back, as he has created GQuery, an implementation of jQuery for GWT.
I decided to demonstrate some of the huge benefits of 1.5 by implementing a type-safe JQuery clone in GWT.
That's right, for all those folks who don't want to deal with GWT Widgets, but just want to query, wrap, and manipulate plain old DOM elements in GWT, this article is for you. I'm talking to you, you self-hating Java programmer with an inner Javascript Ninja begging to be let out.
After the GWT compiler gets its hands on it, the example comes in at 5459 bytes. This library can only be achieved with GWT 1.5 features, and gives you:
Joel Webber of the GWT Team just submitted a patch to GWT 1.5 that implements every DOM2 Core+HTML class as a subclass of the new JavaScriptObject. This not only made the coding of GQuery very easy, but it produces nicely optimized JavaScript.
Static Imports. The $ function would not nearly be as nice without static imports.
Generics and Covariant return. The Plugin mechanism utilizes this to fake prototype based overrides of the GQuery object.
Fun little feature, $$
jQuery contains a lot of methods which take essentially property/value pairs in a Javascript object literal. Emulating this with Java syntax would be too tedious (Scala frontend to GWT, please!), however, to ease this use case, I added a global $$ function for manipulation JavaScriptObject/JSON objects easily.
The main idea behind GChart is simple: You can make very nice charts efficiently out of a reasonably small number of 1-cell Grids (for the aligned labels) and (empty) Images (for everything else), styled and positioned appropriately on an AbsolutePanel. Not surprisingly, bar charts don't suffer at all under the limitations imposed by this strategy--but (as long as you don't mind using dotted connecting lines or banded-filled pie slices) line and pie charts also do remarkably well.
With version 2.0 the library adds support for pie, line, and area charts, baseline-based bar charts, and more.
Reading this, you may wonder how I ended up implementing pie slices
and arbitrary angled connecting lines. Did I use the "transparent
border triangle trick" and/or clever algorithms from walterzorn.com?
Though I tried to use these, I reverted to something a lot simpler:
dotted connecting lines and banded-filled pie slices. Two new Symbol
class properties, fillSpacing and fillThickness, let you control the
spacing of the dots/bands and their size/thickness.
Though this approach means you may sometimes have to choose between
visual chart quality and speed, these new properties make it easy for
you to control this tradeoff. Besides, I like to think that dotted
connecting lines and banded fill pie slices really don't look all that
much worse than the solid fill variety. But then again, I could never
understand why no one ever used square pie charts...
In any case, the whole point of GChart is to layer the chart on top of
standard GWT Widgets, so, since those Widgets can only really draw
rectangles efficiently, I decided to make a virtue of necessity and
whole-heartedly embrace this dotted/banded look.
CSS Convenience Methods: A cure for "CSS anxiety disorder"?
For many months I suffered from "CSS anxiety disorder": a condition
arising from one's desire to use CSS to specify an attribute (and thus
conform to a GWT best practice) while simultaneously wanting the same
property in the Java API (so that it would not be unnaturally
segregated from closely related features).
To address this (possibly imaginary) problem, the GChart 2.0 Java API
includes "CSS convenience methods" that can (optionally) override
traditionally CSS-based attribute specifications for certain selected
CSS attributes.
To some, this may seem like a fine point, since you could easily do
the same thing via a GWT DOM class method call, but to me, once you
invoke a DOM method you are thinking of the GChart as an HTML element,
and for some usage scenarios, that just isn't logical.
For example, for some applications, the background color of a GChart
is mainly about how the color-scheme of the chart blends in with the
surrounding page, and for these applications a CSS-based specification
makes good sense. Yet, for other applications, it is mainly all about
how well background color matches with, say, with the pie slice
shading pattern. That is, in some cases, background color is better
viewed as a feature of the GChart considered as a Java object
independent of its connection to any web page. So why can't you just
call GChart.setBackgroundColor in such cases? With GChart, you can.
To assure that the two specification methods can exist harmoniously
together, GChart recognizes a special property value, GChart.USE_CSS,
which instructs GChart to stand aside and allow the traditional CSS
cascade to define the attribute. For all such "dual access" GChart
Java properties (which are simultaneously also CSS attributes),
USE_CSS is the default property value. This assures that you can use
CSS just as you would with a standard GWT Widget whenever it makes
more sense to control that attribute from the "GChart as HTML element"
perspective.
Thanks to these CSS convenience methods, I have attained inner peace
through Java/CSS redundancy. I recommend the same treatment for anyone
else suffering from "CSS anxiety disorder". See the GChart.USE_CSS
javadoc comment for more information.
I am sure that John will be porting this to the GWT for JavaScript 2 at some point soon!
The Google Web Toolkit has long been a bastion of Java developers who are able to chant "We don't want your stinking JavaScript!"
GWT is a lot more than a client side framework that allows you to write code in Java. It is a productivity tool that lets you developer and test a solution that performs well and works cross browser (huge wins). In fact, when I talk to people that are using GWT, the most common comment that I hear is how happy they are with:
How the application just works cross browser
How great it is to get a new version of GWT, run the new compiler, and get substantive performance improvements
Why should this just live in a Java world? Today, it breaks out. Google has released GWT for JavaScript 2.
With the upcoming birth of JavaScript 2 hopefully hitting our browsers, wouldn't it be nice to build your Ajax applications using JavaScript, but also having the cross browser helpfulness that GWT gets you.
How does it work?
You write an application using JavaScript 2, and you then run it through a compiler which spits out the same optimized JavaScript source code that works for the various browsers.
Why write cross browser JavaScript when you can just write JavaScript?
This fits in perfectly with Steve Yegge releasing js2-mode, a new JavaScript 2 module for Emacs that has a lot of great features:
When making ChartMaker on the plane, I was tempted to use GWT Ext, but it didn't support Ext 2.0 yet so I held off. However, at JavaPolis I was told about the work being done by Sanjiv Jivan, and he has just released GWT Ext 2.0 which "is a powerful widget library that provides rich widgets like Grid with sort, paging and filtering, Tree’s with Drag & Drop support, highly customizable ComboBoxes, Tab Panels, Menus & Toolbars, Dialogs, Forms and a lot more right out of the box with a powerful and easy to use API."
Sanjiv actually added a partial port of Chart Maker as one of the demos. There are a couple of nice touches in there. The one that jumps out at me is the way you add data. Instead of my cheesy textarea, he added a really nice data entry system. Thanks Sanjiv!
If you are a GWT developer that loves staying in Java land, you can continue to do so knowing that you will be getting fantastic looking widgets via Ext 2. A nice pairing.
We posted about JSTM for GWT back when I saw it at JavaPolis.
Now, the project has been renamed to XSTM which comes with a new book, and a new form example:
The data entered in the form is automatically replicated on the server. If you launch two browsers and modify the same field concurrently, the conflict is detected and the last modification is cancelled.
The undo button aborts the current transaction, which cancels the modifications that where done to the form.
XSTM is a library which enables high performance object replication between processes. With it you can set a value to a field of an object in one process and see the value changing on an object in another process. This can be very useful in scenarios where the same data is present on several machines like client-server communication, application clustering, peer to peer etc…
In a client-server configuration, XSTM can replicate changes made to an object to and from selected clients. This simplifies a lot for example Ajax applications where clients interact with the server in complicated ways. Using XSTM, you can forget all the error-prone code to call the server or notify the clients of a data update. No more intermediary objects you send back and forth. No useless copying of fields from objects to objects. No call to the server sending a whole form when only one field has been changed. Model your application in the usual object oriented way, write the code that creates and modifies those objects on the server and the clients, and let XSTM handle the synchronization.
XSTM is symmetric, which means you can put the code which modifies your shared objects on the machine that's best suited. For example form validation code would be identical on a server or on the clients so you can choose the best solution for your application.
