What’s the difference between the two blocks below?
Answer: One’s a canvas and the other are div tags.

This might not seem that interesting at first so here’s the interesting bit: The Div’s background is actually taken from the Canvas. There’s only one Canvas on the page so how’s that working?
Answer: A CSS class is dynamically created with its background set to the base64 output of the Canvas!

Yes, you can get the base64 encoding of any canvas element using canvas.toDataURL().

var base64 = canvas.toDataURL("image/png");

This was news to me but the connection was that the base64 data can then be used in a new CSS rule to with the data being the background, just like you’d do with a tiny image.

* Side note: It’s common to base64 encode images and directly embed them into the CSS file provided they are small enough. Base64 encoding is typically 33% larger than the binary data but you save the HTTP request. If you Sprite your images into one big file it’s less of a savings. Again, all things in engineering are a balance/compromise so do what makes sense for your situation.

var newClass = ".newClass{  background:url("+base64+");} ";
$("<style type='text/css'>"+size + newClass + "</style>").appendTo("head");

I then rotated the divs with CSS3 just for kicks.

<div style="-webkit-transform: rotate(-10deg); -moz-transform: rotate(-10deg); transform: rotate(-10deg);">Hello</div>

Here’s the relevant code all in one piece:

// grab the data
var base64 = canvas.toDataURL("image/png");

var newClass = ".newClass{  background:url("+base64+");} ";

$("<style type='text/css'>" + newClass +"</style>").appendTo("head");

$('#box div').addClass("newClass");

So why would you ever do this? I suppose you might do this to avoid creating a lot of smaller canvas tags. I haven’t checked but I’d wager the overhead for a canvas is higher than that of a CSS rule. You can create one canvas image and then use it all over the place with CSS.

You could implement rounded corners with this but it’s probably the most complex way of doing rounded corners ever so wouldn’t recommend it there either.

One possible use of this is to take a copy of an image as it’s being built. E.g. Canvas images are bitmaps and there’s no “undo”. Unlike SVG, they don’t modify the DOM so you can’t add and remove elements of the image. Imagine a graph built using Canvas, if the user modifies the graph it might be useful to take a copy of it before the modification. You could do this by dumping the base64 data and displaying as a CSS image, rather than creating a 2nd canvas element. I’m reaching here but you get the idea.

I’m not sure this will ever have a practical application. For now it’s just an interesting tech experiment and another example of the cool stuff possible with HTML5.

Identicon5 is a JQuery plugin that takes an MD5 hash and converts it to a unique image. It’s called Identicon5 since it works through the HTML5 Canvas element.

Working Demo is here: http://francisshanahan.com/identicon5/test.html

Project page is here: http://francisshanahan.com/index.php/identicon5

JQuery Plugin page is here: http://plugins.jquery.com/project/identicon5

Identicons provide a nice visual representation of a user’s identity, that’s unique to that user, without divulging any private information. You’ve probably seen them in use on many social websites e.g. http://stackoverflow.com

Identicons are the little geometrical profile images for certain users. Normally Gravatar.com serves up an image based off the MD5 hash of your email address. If you’ve defined a profile image it’ll serve that but if not it’ll show your Identicon, this blog itself is Gravatar enabled as are most WordPress installations.

EXCERPT from Wikipedia

An Identicon is a visual representation of a hash value, usually of the IP address, serving to identify a user of a computer system. The original Identicon is a 9-block graphic, which has been extended to other graphic forms by third parties some of whom have used MD5 instead of the IP address as the identifier. In summary, an Identicon is a privacy protecting derivative of each user’s IP address built into a 9-block image and displayed next the user’s name.

A visual representation is thought to be easier to compare than one which uses only numbers and more importantly, it maintains the person’s privacy.

The Identicon graphic is unique since it’s based on the users IP, but it is not possible to recover the IP by looking at the Identicon.

If you have page with a lot of Users listed, either because there are a lot of contributors on the thread, you might end up with a lot of Identicon image links. Each image is small, about 1kb and carries an HTTP connection as additional overhead. This isn’t really a big problem given today’s bandwidth on the Desktop but on my Droid it becomes an issue. Besides, with HTML5 we can do better.

Identicon5 takes the same MD5 hash value and draws the image dynamically using a Canvas element within the browser. This eliminates the HTTP call and saves you 1kb per profile image. If Canvas is not supported it’ll degrade into a standard img tag linking to Gravatar.

How does Quilting enter into it? Don Parks came up with the notion of using small tiles, arranged in a 3×3 grid per Identicon. The process uses a selection of smaller shapes in each 3×3 grid square and either rotates it or colors it depending on the input value. This is essentially how quilts have been made for hundreds of years.

I’m sure this won’t be the most popular jQuery plugin ever but the idea of applying newer technologies such as HTML5 Canvas to solve a problem that would traditionally have been fixed with a network call was very interesting to me so just had to hack it together.

This is a very tangible example of how HTML5 will make the web more scalable.

As always I’m using a little “test project” as my sandbox, this is a real-world website that’ll use all these features and I’ll share that when it’s done.  So far I’m using oAuth/Twitter integration, ASP.NET MVC/JQuery as a basic stack and am adding in HTML5 and CSS3 features. The resulting site will not be pretty but the point for me is always to get more exposure than having just read the brochure.

This time around the topic is form controls.

I hate forms, they are so boring and my luddite brain can never seem to figure out how to lay them out properly. There is nothing interesting about forms, what could HTML5 possibly bring to the equation?

I was pleasantly surprised; HTML5 under “Web Forms 2.0″ adds a bunch of new form input types. In HTML4 you have

<input type="text" id="someText" />

In HTML5 you can actually specify the type with a bit more semantics, e.g. “tel” for telephone or “number” for integers and the browser will apply some basic masking to the field.

Number and Date types are fairly typical but I was surprised how specific these get, e.g. “type=color”, “type=url” and “type=search”.

Another interesting one is “type=range” which allows a text field to be accessed via a little slider control. Before I would’ve had to implement something like a JQueryUI Slider, now the browser will handle this for me natively. Here’s an example:

</div>
<div><input type="range" min="10" max="90" /></div>
<div id="_mcePaste">

In addition to new input types there are also new attributes which will further reduce the amount of client-side javascript needed for forms. E.g. the  “required” and “autofocus” attributes do as their names imply. This is where CSS3 comes in with its pseudo-classes. E.g. input fields now have a pseudoclass called “valid” and “invalid”.  I can style these like this:

input:valid {
background-color: red;
}

input:invalid {
background-color: red;
}

When a field tagged with “required” but it’s empty, the browser *should* assign this pseudo-class and render it accordingly. Hey, that’s saving me some more boiler-plate Javascript.

Some interesting ones though are “min” and “max”, e.g. when applied to a “type=number” or “range” will determine the limiting values for the control. Excellent.

I’ve looked at the spec ( http://www.whatwg.org/specs/web-apps/current-work/ ) and do have some questions still such as how to localize things like the telephone field masks? I’m sure we’ll see some more on this in the future.

Besides simpler coding, these new semantics should also improve accessibility. Things like JAWS can now distinguish required fields from the DOM and determine that field A is an email vs field B being a search box.

This is all fairly new so the specifics of what each browser does will likely flex a bit until fully bedded down, most of these don’t do anything (yet). At least the markup is there now and I’m liking where this is headed.

Here’s a simple test page I came across for reference: http://miketaylr.com/code/input-type-attr.html

As always you can check with http://caniuse.com for a detailed rundown of who’s supporting what.  (Opera’s had this stuff for quite a while now).

SVG as we know has been around a few years although has not really found a firm foothold in the world of web development. I  didn’t realize but even IE6 supports SVG.  So why the slow adoption?

It seems the standard for SVG took a long time to get settled and performance is not great.  SVG is based on vectors so they zoom/scale really well without any pixelation. On the downside they manipulate the DOM so the browser’s memory and CPU requirements can become quite large.  What’s nice is you can save to SVG path format from a lot of drawing applications such as Illustrator.

The <canvas> tag is new in HTML5 and essentially is a bitmap that’s procedurally manipulated using javascript. It doesn’t create new elements in the DOM and is relatively faster than SVG as a result.  Graphics don’t zoom or scale as in SVG but I suppose you could simulate this behaviour since the image is procedural (built from instructions).

Boris Smus has a nice post comparing the performance of each : http://www.borismus.com/canvas-vs-svg-performance/

There are libraries to help you with each implementation, here’s a couple I found whilst researching graphs:

• RaphaelJS for SVG (recently acquired by Sencha (www.sencha.com) formerly ExtJS.com) and
• RGraph.net for <canvas> (www.rgraph.net)

So, which one to use? As always it depends on the need. I’m looking to replace OpenFlashChart currently with rGraph.net and give it a whirl. Flash is too heavy and slow for my simple graphing needs and I want to be buzzword compatible. SVG paths are a little funky, especially if I’m going to be manipulating them dynamically so I’ll go the HTML5 route.

Check with http://caniuse.com for browser compatibility and degrade with http://modernizr.com to tick the least number of users off.

An XHTML 1.0 transitional website was a great place to start. I used the trusty w3c validator located at http://validator.w3.com.

First thing was to get the Doctype fixed up: I changed

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

to

<!DOCTYPE html>

and bingo, we’re recognized as HTML5 instead of XHTML. Not compliant yet though. I removed the profile attribute from my head tag as so:

<head profile=”http://gmpg.org/xfn/11″> which wasn’t serving any purpose anyway so it became

<head>

Removed a stray </link> tag from the header, added an alt tag where there was one missing, removed px from all width and height attributes and removed a frameborder tag (obsolete).

That completed the HTML5 cleanup. At this point the site validated but was not actually using any tags.

Next up adding some HTML5 semantic tags: I added the <header> and <nav> tags in the appropriate places, defined a <section role=”main”> tag for the main area of the page. Slapped in some <article> and <header> tags. The only one worth mentioned was the <time> tag which took a different format from the datetime I was using so it’s:

<time datetime=”<?php the_time(‘Y-m-d’) ?>”></time>

And lastly added a <footer> tag. In terms of the theme I touched header.php, footer.php, index.php and single.php. Easy stuff and now I’m fully geeked out on HTML5.

Webhost4life was a good host for many years but something changed recently. The site was moved to a new platform without warning.

It was ported to new servers, which I’m guessing are virtual. My SSL certificate disappeared in the process. My site worked slower…MUCH slower and was out of service numerous times. Not only that but the configuration changed. The new platform doesn’t support .NET 4.0 or the .NET Wildcard mapping in IIS. Support switched to a “premium” service which had to be paid for. All tickets I opened were answered only after 1-2 hours and even then only with a stock response of “we apologize and your issue has been routed to a specialist”. With service like that I don’t need ‘em.

Here’s hoping Arvixe is better and so far so good.

Yeah, yeah, we’ve heard this all before but the big question is when is it going to happen and how?

The technology that’ll power this is undoubtedly HTML5.

Looking at the desktop market-share we see that

1. Firefox – 31.26%
2. Internet Explorer 8 – 25.23%
3. Internet Explorer 6 – 18.11%
4. Internet Explorer 7 – 12.59%
5. Chrome – 7.72%
6. Safari – 5.15%
7. Opera – 1.98%

Reference – http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

If you want to know the HTML5 story you must look at the rendering engine used by these browsers.

All browsers render web pages through the use of a “rendering engine”, this is what how the HTML, CSS is interpreted and turned into a visualization of the page. Current rendering engines are WebKit (Safari, Chrome), Gecko(Seamonkey, Firefox) and Trident (Internet Explorer) with some other outliers.

Wikipedia details how well the rendering engines compare in terms of HTML5 support [LINK] and we find that WebKit is leading the pack.

Webkit-powered browsers have the least market share on the desktop (right now) but the highest market share on mobile devices. In fact in February RIM made indications that it was planning to move the Blackberry to a WebKit powered device.

According to NPD [link]:

“Currently, BlackBerry leads the pack with 36% of market share of smartphones with Android following closely with 28% and iPhone chugging along at 21% for the 2010 sales”

Add that the recent introduction of the iPad which no doubt uses Webkit in some form for its browser and you have the perfect storm of WebKit support on smartphones (excluding other mobile devices such as traditional cell phones which don’t really factor into this discussion).

Consequently It seems Smartphones/Pads will be among some of the first devices to really support HTML5. Smartphone user base grew at somewhere between 10-20% in 2009 and by 2011 50% of all phones sold are expected to be smartphones. Clearly there is huge demand for this technology. Even today, my Dolphin Browser running on android is scoring a “144 out of a possible 300″ for HTML5 support whereas IE8 on Windows 7 scores a pitiful “27″.

What does this mean in terms of IT? Well HTML5 fills a lot of gaps. Better browser APIs, more advanced media playback, offline storage, vector graphics support, intra-browser communication and better markup.

If you’re looking at making a presentation-tier investment then JavaScript, CSS and HTML 5 remain your best choices. I expect Flash to continue to hold court in certain areas but with an ever-greater spotlight being shone on security I’d expect a drop off of some kind. I really don’t see the point of AIR anymore and any future needs for vector graphics can be directed to the HTML5 standard. Silverlight? JavaFX? Well who’s to say but right now I could not justify an investment in these technologies by any stretch of the imagination.

It’s a good time to be a developer; Javascript, CSS and HTML skills will be ever more in demand, dev tools in the area will become first-class citizens and who knows, we may even see some decent code-coverage tools for the client-side.

You can check your browser’s support at http://html5test.com/.

The image on this post is a capture of the SVG Tiger, typically used as a test case for vector graphics support (similar to the OpenGL Mandril). You can find an actual vector-rendering of same using an HTML5 capable browser and Raphael here [LINK]

As a side-note, GWT’s big value add is that it generates JavaScript off of Java. It also does some things during compilation which will speed up the JavaScript it produces de-virtualizing methods and so forth. We used to do this back in the day with C, unwinding loops, in-lining assembly code and so on. GWT does similar stuff to shave milliseconds off processing time. However, it’s questionable since GWT’s flagship application: Google Wave has a resource profile that weighs in at a whopping 3MB and looks like this:

The first thing you need is an interface, this has to go in your client package from what I can tell:

Human.java:

package com.crap.crapGWT.client;

public interface Human {
   void WhatAmI();
}

Then you need a couple of classes that implement this interface:

Woman.java:

package com.crap.crapGWT.client;

import com.google.gwt.user.client.Window;

public class Woman implements Human {
	public void WhatAmI() {
		Window.alert("I'm a lady");
 	}
}

and

Man.java:

package com.crap.crapGWT.client;

import com.google.gwt.user.client.Window;

public class Man implements Human {
	public void WhatAmI() {
		Window.alert("I'm a dude");
 	}
}

In onModuleLoad() add the following:

Human myHuman = (Human)GWT.create(Human.class);
myHuman.WhatAmI();

Then you define some properties, you can put the following in your main module XML file OR you can put it in its own file. If you do the latter you must inherit that XML file in the main module.

<define-property name="human" values="man,woman" />
	<property-provider name="human">
<![CDATA[
     return __gwt_getMetaProperty("human");
]]>
</property-provider>

Believe it or not the above is actually JavaScript! (wasn’t this what we wanted to avoid by adopting GWT?)

Then in your main XML module put the rules by which the classes are swapped out. E.g. below, if you find a human property set to “man” replace this with the Man class.

<replace-with class="com.crap.crapGWT.client.Man">
	<when-type-is class="com.crap.crapGWT.client.Human" />
	<when-property-is name="human" value="man" />
</replace-with>

<replace-with class="com.crap.crapGWT.client.Woman">
	<when-type-is class="com.crap.crapGWT.client.Human" />
	<when-property-is name="human" value="woman" />
</replace-with>

And finally add in the actual property itself in the HTML file in your WAR.

<meta name='gwt:module' content='js/gwt=com.crap.crapGWT.client.Human'/>
<meta name='gwt:property' content='human=woman'/>

If everything goes well you should get a popup saying “I’m a lady”.

If you have trouble, go back and check everything, particularly the class namespaces. If all looks well yet you still can’t get it to work, restart Eclipse (*yes* I’m not kidding).

Then finally change the property to a “man” and you’ll get a different message.

<meta name='gwt:property' content='human=man'/>

You can try this also:

if (myHuman instanceof Human) Window.alert("myHuman is a Human");
if (myHuman instanceof Man) Window.alert("myHuman is a Man");
if (myHuman instanceof Woman) Window.alert("myHuman is a Woman");

So that’s Deferred Binding.

My Use Case is I want to generate a screen off of metadata and have it hooked to events written in Java code.

First you’ll need an interface that will be used to trigger the Generator. Anytime compiler sees this interface it’ll swap in a generated class.

package com.crap.crapGWT.client;

import com.google.gwt.user.client.ui.RootPanel;

public interface ScreenObject {
	void PaintScreen(RootPanel rp);
}

Next you need an implementor of that interface

package com.crap.crapGWT.client;

import com.google.gwt.user.client.Window;
import com.google.gwt.user.client.ui.RootPanel;

public class ExampleScreen implements ScreenObject {

	@Override
	public void PaintScreen(RootPanel rp) {
             // Leave this empty
	}
}

Next you need a flag in the main GWT XML module file:

<generate-with class="com.crap.crapGWT.server.WidgetGenerator">
	<when-type-assignable class="com.crap.crapGWT.client.ScreenObject" />
</generate-with>

The above tells the compiler to trigger the generator (WidgetGenerator). This needs to go in your server code, not the client or shared.

package com.crap.crapGWT.server;

import java.io.PrintWriter;

import com.google.gwt.core.ext.Generator;
import com.google.gwt.core.ext.GeneratorContext;
import com.google.gwt.core.ext.TreeLogger;
import com.google.gwt.core.ext.UnableToCompleteException;
import com.google.gwt.core.ext.typeinfo.JClassType;
import com.google.gwt.core.ext.typeinfo.NotFoundException;
import com.google.gwt.user.rebind.ClassSourceFileComposerFactory;
import com.google.gwt.user.rebind.SourceWriter;

public class WidgetGenerator extends Generator {

	@Override
	public String generate(TreeLogger logger, GeneratorContext context,
			String typeName) throws UnableToCompleteException {
		// Build a new class, that implements a "paintScreen" method
		JClassType classType;

		try {
			classType = context.getTypeOracle().getType(typeName);

			// Here you would retrieve the metadata based on typeName for this Screen
			SourceWriter src = getSourceWriter(classType, context, logger);
			src.println("public void PaintScreen(RootPanel rp) {");		

			// Here you would iterate through the metadata adding elements to the code
			src.println("Button myButton = new Button(\"Click Me\");");

			// Now hook up the events, in this case the naming convention is <Class>Events so
			// "ExampleScreen" becomes "ExampleScreenEvents"
			src.println("myButton.addClickHandler(new " + typeName + "Events());");
			src.println("rp.get().add(myButton);");

			src.println("}");
			src.commit(logger);

			System.out.println("Generating for: " + typeName);
			return typeName + "Generated";

		} catch (NotFoundException e) {
			e.printStackTrace();
		}
		return null;
	}

	public SourceWriter getSourceWriter(JClassType classType,
			GeneratorContext context, TreeLogger logger) {
		String packageName = classType.getPackage().getName();
		String simpleName = classType.getSimpleSourceName() + "Generated";
		ClassSourceFileComposerFactory composer = new ClassSourceFileComposerFactory(
				packageName, simpleName);
		composer.setSuperclass(classType.getName());
		composer.addImplementedInterface("com.crap.crapGWT.client.ScreenObject");

		// Need to add whatever imports your generated class needs.
		composer.addImport("com.crap.crapGWT.client.ScreenObject");
		composer.addImport("com.google.gwt.user.client.Window");
		composer.addImport("com.google.gwt.user.client.rpc.AsyncCallback");
		composer.addImport("com.google.gwt.user.client.ui.Button");
		composer.addImport("com.google.gwt.user.client.ui.RootPanel");

		PrintWriter printWriter = context.tryCreate(logger, packageName,
				simpleName);
		if (printWriter == null) {
			return null;
		} else {
			SourceWriter sw = composer.createSourceWriter(context, printWriter);
			return sw;
		}
	}
}

This is the meat and potatoes of the business. You’ll see the code is doing a println to print out the actual Java that’ll then be coupled with the rest of the project. Very messy stuff.

You’ll also notice I’ve tied the button above to an event Handler implemented in “” + “Events” so in this case ExampleScreenEvents.java:

package com.crap.crapGWT.client;

import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
import com.google.gwt.user.client.Window;

public class ExampleScreenEvents implements ClickHandler {

	@Override
	public void onClick(ClickEvent event) {
		Window.alert("Hello from onClick of MyExampleScreenEvent Handler");
	}
}

Finally you need to create the screen, in onModuleLoad just add the following:

ScreenObject s = GWT.create(ExampleScreen.class);
s.PaintScreen(RootPanel.get());

Presto, it works. Run the sample, you’ll see a button added to the form, click it and you’ll get the hello world message.

There are a lot of issues with this. If you make a mistake, your code will break at compile time which is good, but since it’s breaking on a generated file, you’ll need to go digging in the TEMP folder to find the actual Java code that’s broken. For me this was located in C:\Documents and Settings\fs11782\Local Settings\Temp\ExampleScreenWrapper4091248644661218253.java
Exactly like T4 templates. Very messy.

The code is written out using strings, that makes it tough to maintain. It was very often necessary to import the generated file into the project to see what the issue was, then adjust the generator and then run it again.

Every time I did this Eclipse failed to recognize the changes and would only pick them up after a shutdown/restart of the IDE.

Generators in GWT: not recommended but there you are.

Let’s take a step back; GWT is supposed to solve the “problem” (false premise) of writing JavaScript. JavaScript is “bad” because it’s a dynamic language, loosely typed, interpreted and so on. Yet those are also advantages. Thinking back a few years I seem to recall a similar discussion between Lisp programmers and C++. By introducing Generators, I’ve actually lost all the perceived benefits of GWT, writing code out as a println() for example. I do get to write my code in Java but at a fairly high cost and high level of complexity with multiple layers of abstraction introduced into the solution.

Using ExtJS you can create a screen programmatic-ally using classes and method calls but one of the neat features is that a screen can be entirely described declaratively in JSON notation. Declarative UI is nice, but a meta-data driven UI is nicer. I’ve created such systems in the past but always had to spend so much time maintaining the thing that interpreted the metadata (Sapient Powerbuilder Framework anyone???).

With ExtJS this could be avoided by just serializing the JSON into a database and back again. Eureka! I had a pretty nice metadata driven declarative UI with MINIMAL investment in “framework” code. Minimal investment in this type of “framework wrapper stuff” corresponds to a good upgrade path, quick time to market and very low likelihood that my “metadata wrapper” would break anything in the underlying ExtJS library.

Intrigued and not wanting to practice “architecture space exploration” [LINK] I wrote a proof of concept and built some screens out of metadata.

There was just one snag; ExtJS could paint the screen but in order to wire it to data it needed a bit of Javascript code to be written. With a complex screen this JS might grow to as much as 200-300 lines. Debugging JS with Firebug, Dynatrace etc. doesn’t scare me but it doesn’t sound good to an architecture review board either.

No good deed goes unpunished. It was mentioned that GWT could be used to write the same thing except instead of Javascript, developers could wire up their screens with Java code. The promise of Eclipse, PMD, FindBug and all that java-y goodness was just too much to argue against so I’ve spent the last few weeks in GWT hell and finally come full circle.

<rant>Just a second, hey, why did I do this? Well I like to know what I’m talking about. If I’m going to be responsible for something I want to know it’s going to work BEFORE we start. I don’t want to be an architecture astronaut who just reads the brochure. Everyone can read the brochure. I wouldn’t follow someone like that and I don’t expect my team to. </rant>

GWT (Google Web Toolkit) is essentially a compiler that takes your Java code and instead of byte code produces JavaScript. It does a nice job, traversing code paths so that only the bare minimum Javascript is sent down to the browser. It looks like a dogs dinner though.

Enter Ext GWT, Smart GWT (formerly GWT Ext) and MyGWT. Seems everyone has a GWT library, never a good sign imho.

GWT needs to know every execution path at compile time and hence it doesn’t support reflection. First problem was how to paint the screens from metadata. This can be achieved with GWT.create() but wiring the widgets to Java code with string literals is not possible.

In my use case, the developer should configure the metadata, the framework should paint the screen, the developer should write some Java code for screen logic, then wire the two together. There’ll be 300+ developers worldwide of varying experience levels so it’s gotta be simple to use.

I looked at Deferred Binding; “Deferred Binding is Google Web Toolkit’s answer to Java reflection.” BINGO!!! that’s got to be exactly what I’m looking for, it even says “reflection” on the box.

From http://code.google.com/webtoolkit/doc/1.6/FAQ_Client.html

One way to think of this is as “dynamic class-loading that occurs at compile time instead of execution time.” When the GWT Compiler compiles your Java application, it determines all the different “idiosyncrasies” that it must support, and generates a separate, tightly streamlined version of the application for that specific configuration. For example, it generates a different version of the application file for Firefox than it does for Opera.

reading on…

It’s probably pretty clear by now that Deferred Binding works a little differently than standard dynamic binding. Conceptually, though, the two concepts are fairly similar, and in practice all you usually need to do is just substitute a GWT method for a Java Reflection method. Instead of Class.forName(“MyClass”) you use GWT.create(MyClass).

So although Deferred Binding is the GWT’s answer to reflection, you cannot invoke a method using a string literal, you cannot create a class unless it’s known at compile time and you cannot hook up to an event without compile-time knowledge of the handler.

This makes metadata a pretty tough proposition. To add to the frustration, examples for Deferred Binding were so thin on the ground that it took me 2 evenings to get something working. I’ll post an example in the coming days to “pay it forward”.

Not to be outdone I looked at Generators. Again, no examples to be found anywhere, I’ll post one in a day or two. Generators basically let you generate java code at compile time, this code you never see but is then turned into Javascript. Honestly the GWT compiler must make 10 passes.

Generators could work. Using Generators would possibly allow the creation of a metadata UI framework however, it would take an enormous amount of fairly skilled coding to make this happen. They’d also be very brittle and tough to build; e.g. you have to write out java code using the GWT equivalent of a printf. You’ve no way of knowing if the code will run or not until it’s too late. Certainly very little chance of testing it. Rocket [LINK] claims to fix this problem but frankly this project is far too immature to be of any use.

Gwittir [LINK] is another option that claims to support Reflection. That’s dependent on GWTx and Google Gears. One of my pet-peeves about the open source world is all the dependencies. Don’t make me download 10 other things/frameworks just to draw HelloWorld. GGears is not an option for me so Gwittir is out.

Lastly, all these frameworks claim to optimize the Javascript, and they are true to that claim, HOWEVER, the third party libraries like SmartGWT, ExtGWT, etc. don’t optimize the widget Javascript. If you’re using SmartGWT’s grid, guess what, you’re downloading 500KB of widget JS.

So I’ve come full circle. For me, ExtJS seems like a good fit, easy to use, easy to drive off metadata and sure I have to write some Javascript but I’ll take a few lines of Javascript/Firebug over the mess that is Deferred Binding and Printf-style Code Generation anyday. Don’t knock it OR recommend it until you’ve tried it and fly safe.