Interview: Creator of Metawidget, the Automatic UI Generator

Tired of handcoding your user interfaces? Even if you use a GUI builder, you still need to update the user interface components when the model changes. Richard Kennard has a solution: Metawidget. Metawidget is an object/user interface mapping tool and an open source project. Metawidget inspects an application's existing back-end architecture and creates components native to its existing front-end framework. Here we learn all the details from Richard himself.

Hi Richard, first please tell us who you are and what you do?

I'm Richard Kennard and I'm an independent software consultant. I specialize in Java EE development and serve on the JSR-299 (Web Beans) Expert Group. I'm based in Sydney, Australia.

What is Metawidget and what problem does it try to solve?

Metawidget takes your existing back-end domain objects and creates, at runtime, UI components native to your existing front-end framework:

Developing UIs is very time consuming, so any automation is a real boon. But current solutions tend to do either too little or too much. For example, visual builder tools are great, but you still have to drag and drop every field and label and rework your UI as the back-end code changes. There are other tools that try to auto-generate your entire UI, but they end up dictating how it looks, what framework it uses, etc.

Metawidget tries to find the 'sweet spot' of automatic UI generation: just enough to be useful, not too much that it constrains you. You just give it your existing domain object:

public class Person {

	private String fullname = "Homer Simpson";
	private int kids = 3;
	private boolean retired = false;

	public String getFullname() {
		return this.fullname;
	}

	public void setFullname( String fullname ) {
		this.fullname = fullname;
	}
	//...more getters and setters...
}

And Metawidget gives you a component ready to slot into your existing UI:

How did you come to create this project, can you remember the moment where you first started thinking about it?

I remember the first releases of JPA were coming out. I thought being able to annotate your domain objects instead of writing XML mapping files was awesome - it had this real spirit of 'Don't Repeat Yourself'. We'd gone from having to manage duplicate field declarations in 3 places (your database schema, SQL statements, domain objects) to just 2 places (your domain objects and an XML mapping file) to just 1 place (an annotated domain object). I thought that was great.

But then I turned around and still had to type <input type="text" name="company">. It got me thinking 'why is the UI special? How come I still have to manage duplicate field declarations in my UI layer'?

So I built an auto-generating Java Server Faces component. I used and refined it across projects for a couple of years and it proved a real time saver. Then I broadened it to support multiple front-end frameworks (Swing, Spring, Struts, Android) and multiple back-ends, and it became Metawidget.

Can you outline the different scenarios in which Metawidget could be useful?

If you've got an application with several input screens, Metawidget can save you a huge amount of time and code. And when you later add and refactor fields, Metawidget will rework your UI automatically. And if you need to support multiple UIs for the same project (desktop, web, mobile) Metawidget keeps them all in sync for you.

At the time of writing, Metawidget supports the following front-ends: Android, Java Server Faces (including JBoss RichFaces), Java Server Pages, Spring Web MVC, Struts, and Swing (including Beans Binding). On the back-end, Metawidget supports Annotations, Hibernate, Hibernate Validator, JavaBeans, and Java Persistence Architecture. And the architecture is designed to encourage people to plug in more!

Can you walk us through an example of how Metawidget integrates with an existing framework, such as Beans Binding?

Metawidget 'drops in' to your existing environment and uses whatever is available. In itself it doesn't have any JAR dependencies - instead it leverages as many frameworks as it finds.

So if you have Swing on the front-end, Metawidget will create JComponents. And if you have Hibernate Validator on the back-end, Metawidget will inspect its annotations for useful UI hints (eg. @Min and @Max for a JSlider). And so on.

If Beans Binding is available, Metawidget will automatically wire up its JComponents to the back-end. You just tell Metawidget what object to inspect:

public class Main {

	public static void main( String[] args ) {
	
		SwingMetawidget metawidget = new SwingMetawidget();
		metawidget.setInspector( new JavaBeanInspector() );
		metawidget.setBindingClass( BeansBinding.class );
		metawidget.setToInspect( new Person() );

		//...add the metawidget to a JFrame...
	}

}

And Metawidget does the rest:

To save the data back, you just do:

.add( new JButton( new AbstractAction( "Save" ) {
    public void actionPerformed( ActionEvent e ) {
	metawidget.save();
    }
} )

Or you can use the full range of Beans Binding sync'ing options.

I've posted the complete code to this example on my blog, in an entry entitled Beans Binding and Metawidget.

Are there any disadvantages to automatic UI generation?

I think the disadvantages come in two forms. One is when automatic UI generation goes 'too far', in other words, when it starts dictating what your screens look like, or how the user navigates between them, or what UI framework they use. Metawidget doesn't do this. It creates only parts of a screen, not the whole thing. And it creates native components and gives you direct access to them. For example, with SwingMetawidget you can just do...

JTextField field = (JTextField) metawidget.getComponent( 1 );

...and you're right there in the Swing API with all its capabilities. So Metawidget doesn't constrain you.

The other disadvantage is when automatic generation doesn't go 'far enough': some approaches require you redefine your business objects in their own framework-specific format or use their own framework-specific tools. Again, Metawidget doesn't do this. It reuses your existing business objects, and emphasizes Metawidget finding information out for itself (via its Inspectors) rather than you having to supply it with information.

So when would one not want to use this approach?

Building great UIs is both art and science. Metawidget doesn't attempt to address the art, it only automates the science.
That is, it doesn't overlap with those areas of UI design involving creativity and subjectivity - so you shouldn't use it there. Metawidget's goal is only to ease the creation of those areas that are already rigidly defined. Typically, this means areas that display data and those that collect data: these tend to be both common place and consistent (indeed, consistency is a desirable trait) so there is good opportunity for automation in these areas.

A new release of Metawidget was recently announced. Can you say something about it?

I'm very much in the 'release early, release often' phase right now. I want to encourage as much feedback as I can to make the 1.0 release as strong as possible.

This latest release adds Hibernate support (it scans your mapping files for useful UI hints, like not-null), upgrades the Android support (Google recently released an upgraded SDK), adds fuller support for Java types (byte/Byte, short/Short, etc.) and general bug fixes and additional unit tests.

Do you work on this project alone? What's the community like around Metawidget?

At the moment Metawidget is just me. But the design is very modular so I'm hoping to attract others to the cause :)

For example, if you've written a UI framework/component library/layout manager, you can make it easier for people to adopt by writing a Metawidget for it. Or if you've got a validation/persistence/rule-based framework, you can make it easier for people to plug in to their front-end by writing an Inspector for it.

What does the future direction of the project look like? What can we expect in the coming months/years?

My immediate focus is to establish the list of features people want to see in a 1.0 release, then solidify support for them.

The longer term goal is to save everybody a lot of time: to find the 'sweet spot' of automatic UI generation that makes it useful enough and flexible enough to become a regular part of everyday Java development.