Kennard Consulting's Blog

What Do You Want In A Generic DAO API?

2012-01-27T14:23:00.016+11:00

I was recently involved in a discussion around a 'generic DAO API'. There's been a lot of Java EE goodness in recent years. Specifications such as JPA, EJB, CDI and JSF have made great strides to simplifying web application development. But anybody attempting to build a CRUD application in Java EE 6 will find there are still significant pieces missing.

Like many others, Kennard Consulting have had their own, proprietary 'generic DAO API' for many years. It's got all the usual features like CRUD, support for relationships, pagination and sorting, bookmarkable URLs, and so on. After 5 years of living with it, it's easy to be retrospective. There are certainly some things we'd do differently!

But I'll just highlight a few things that have worked out quite well. They're a bit unusual, but I think they're things any 'generic DAO API' should at least consider:

Custom EL Resolver

A common (anti?) pattern I see is this:

@Named public class PersonView extends GenericView { // Just for @Named }

In most domains, there are lots of entities. And if your GenericView is any good, it should be able to supply most of the common operations for most of them. But then you still have to derive a skeleton class from the (abstract?) GenericView just to expose it to JSF. This results in a huge number of boilerplate View classes (one per entity).

For our API, we instead wrote a custom EL resolver that knows how to map an EL name to a GenericView automatically (in cases where one hasn't been explicitly @Named). This has saved us a significant amount of code.

To QBE or not to QBE?

Query By Example (QBE) is a great way to develop search screens for CRUD applications. You can specify all the search fields as a Java Object, then write some generic code to translate that into JPA-QL. I would highly recommend a generic DAO API allow you to query using a partially populated version of an entity.

But don't just limit it to the entity class itself! For example, if my entity is:

public class Person { public String getName() { ... } public Date getDateOfBirth() { ... } }

Then sure it's great to be able to do:

Person search = new Person(); search.setName( "John Smith" ); Person found = queryByExample( search );

But it's also very useful to be able to create a specialized Search class:

public class PersonSearch { public String getName() { ... } public Date getBornAfter() { ... } public Date getBornBefore() { ... } }

So that I can do:

PersonSearch search = new PersonSearch(); search.setBornAfter( "1980-01-01" ); search.setBornBefore( "1990-01-01" ); Person found = queryByExample( search );

For this to work, you'll need to be able to annotate the PersonSearch class a little:

public class PersonSearch { public String getName() { ... } @Search( value = ComparisonType.GREATER_THAN, field = "dateOfBirth" ) public Date getBornAfter() { ... } @Search( value = ComparisonType.LESS_THAN, field = "dateOfBirth" ) public Date getBornBefore() { ... } }

But that in itself opens all kinds of interesting possibilities:

public class PersonSearch { @Search( value = ComparisonType.CONTAINS ) public String getName() { ... } @Search( value = ComparisonType.GREATER_THAN, field = "dateOfBirth" ) public Date getBornAfter() { ... } @Search( value = ComparisonType.LESS_THAN, field = "dateOfBirth" ) public Date getBornBefore() { ... } }

We've found such a capability very handy.

Sticky searches

How you relate your entity to your view to your search object is open to a lot of personal preference. We have the view bean manage both the entity and the search object, but that's just us. However one thing our users have asked for is the entity and the search object should have different lifecycles. In particular, the search should be session-based, so that every time the user comes back to the CRUD screen it's still there for them.

Security

Whilst 'security through obscurity' is a bit frowned upon, it's a great safety net! Particuarly when you get down to the level of 'make sure user A can't see record B, even though user C should be able to see it'. It's easy to miss some of the rules. But a few things have really helped:

Unguessable IDs: we use UUIDs for all our identifiers. For practical purposes these are unguessable - avoiding the situation where, say, a user who loads a customer record with an ID of 123 might try to load one with an ID of 124. To minimize the performance impact we store each UUID as a 128-bit integer, not as a String.
Obscured IDs: we encrypt every ID (whether on the URL, or inside the HTML) relative to the logged-in user, preventing a scenario where one user can snoop an ID and try it under their own login.

Temporary names: we use randomly generated names for all our HTML fields (at least in production). Furthermore these change with every page display/POST back.

In conclusion, these are just a few things that have worked out well for us over the past 5 years. They may not apply to your particular 'generic DAO API', but we think they're worth considering. Feedback welcome!

Bulletproof Backups with the ReadyNAS Duo (Update)

2012-01-17T15:39:00.014+11:00

I thought I'd do an update to one of my most popular blog posts: Bulletproof Backups with the ReadyNAS Duo:

I've had my ReadyNAS Duo nearly four years now, and have experimented with all sorts of things and reached some conclusions:

RSnapshot

I struggled for a couple years with versioned backups. Because you have quite a lot of disk space, you can get away with making multiple, complete copies of your data for daily and weekly backups. In fact, using the built-in ReadyNAS software it's the best you can do.

But if you've got thousands of files and most of them don't change often, this feels very wasteful. A while ago I discovered the rsnapshot add-on. rsnapshot only copies files that have changed, and creates hard links for those that haven't. So suddenly you can have many days/weeks worth of versioned backups in very little disk space. Awesome!

However:

Hard Links Are Evil

A warning about hard links. If your ReadyNAS ever decides it needs to check the disk (fsck), all those thousands of rsnapshot hard links will bring it to its knees. This has only happened to me once, thankfully!

Your options in this case seem to be either: kill fsck, delete all your rsnaphot backups (and hence the hard links) and run fsck again. Or wait out the mysterious blue pulsing light:

Mysterious Blue Pulsing Light

Sometimes the ReadyNAS just sits there ominously with a blue pulsing power light. You can't connect to it during these times. Worse, this mystery state can last for hours! If you're like me you installed RAIDar once when you first bought your ReadyNAS, and then forgot all about it. However RAIDar is very useful for telling you what your NAS is doing during these pulsing light times, and stopping you resetting it in impatience.

Root That Sucker

I resisted the EnableRootSSH and ToggleSSH add-ons for years, because if you use them and subsequently mess something up, you probably can't ask for support. But if you're careful they can be very useful.

For example, when configuring rsnapshot, I found it necessary to manually edit /etc/cron.d/rsnapshot and set it to:

0 9,18 * * * root /c/addons-config/rsnapshot/hourly.sh 0 12 * * * root /c/addons-config/rsnapshot/daily.sh 0 15 * * 1 root /c/addons-config/rsnapshot/weekly.sh

This is because by default rsnapshot runs at midnight, but I have my ReadyNAS configured to power down overnight.

Bringing The Horse To Water

Although there's lots of rsnapshot goodness once your data is on the ReadyNAS, actually getting it there can be troublesome. I went through a lot of different backup programs. Some of them are truly awful. I won't name and shame them, but here are some problems to watch out for:

do they have a special driver that syncs the data? These frequently BSOD'ed my PC
do they mess up the folder case when they sync, especially if you have two folders with different case at different places in your heirarchy (e.g. C:\foo\Finances versus C:\foo\bar\finances)
do they have catalogs/indexes/other mechanisms that make them horribly slow to copy thousands of files
can they do file filtering based on wildcard matching
can they exclude folders based on wildcard matching, especially nested folders (e.g. *\tmp\)

The absolute best I found was SyncBackSE. It does it all, and does it fast, and does it without any nasty surprises!

Teaching The Horse To Drink

Even with a great product like SyncBackSE, you still need to take care how you schedule your backups. If you've got thousands of files, even if they don't change often, your backup software still has to scan over them every time.

I settled on configuring half a dozen backup jobs. Critical files were scanned more often (say, hourly) but in small groups (say, just My Documents). Less critical files were scanned less often (say, daily) in larger groups (say, C:\Program Files).

Exactly What It Says On The Tin

The ReadyNAS is a great Network Attached Storage device (e.g. hard drives in a box), but it's pretty lousy for anything else. It's really underpowered if you try to use it as a server, or load it up with too many add-ons or streaming services. If that's what you're after, you really need more than 256MB RAM and a slow CPU. Apparently the Duo v2 is faster, but it's still only 256MB RAM.

Your Mileage May Vary

Some things I got right the first time:

it's definitely too slow to use as an 'active' drive that you run programs off.
keeping all paths relative to some distant drive letter (like N:) is handy for restores.
despite some misgivings, I've had no problems at all powering down the ReadyNAS and swapping drive trays as a way to take off-site backups. However, remember that the drives are EXT3 formatted. This makes them a pain to try and read in Windows, and the ReadyNAS doesn't do NTFS. So it can still take a while to restore all that data into a usable form.

But all in all, the ReadyNAS Duo is a complete win!

Metawidget v1.35: New Static Form Generation

2012-01-10T18:26:00.003+11:00

Version 1.35 of Metawidget, with new static form generation is now available! This release includes the following enhancements:

First version of StaticMetawidget
Support JPA @Temporal
Output HTML <label> tags around labels
Refactor StrutsWidgetBuilder/SpringWidgetBuilder into WidgetProcessors
Bug fixes, documentation and unit tests

As always, the best place to start is the Reference Documentation:

http://metawidget.org/doc/reference/en/pdf/metawidget.pdf

Your continued feedback is invaluable to us. Please download it and let us know what you think.

Forge and Metawidget Discussed On JBoss Community Asylum

2011-12-23T13:16:00.007+11:00

Metawidget, and the work we're doing with the JBoss Forge team, has gotten a nice mention on the latest episode of the JBoss Community Asylum podcast. Here's an excerpt (taken from 35m.22s):

Max: "Right now if you download Forge right now, you get a JSF Metawidget thing"

Lincoln: "Right you get a default scaffolding provider we call them, and that one right now is using - like you said - JSF and Metawidget which we're actually working on the next version of, so that... right now when you run the scaffold it basically looks at your database objects, your JPA objects, it runs through them all and generates a bunch of view files for the Create, Read, Update, Delete operations. You know, a simple interface."

Max: "So this is kind of like what seam-gen did before, right?"

Lincoln: "Right. Kind of like that. And when you look at the output of the scaffold that you would download, maybe from Beta 3, you will see this Metawidget tag and Metawidget is..."

Max: "Yeah why don't you just tell what Metawidget is?"

Lincoln: "Metawidget is a really cool framework actually, it..."

Emmanuel: "We should interview... er... forgot his name..."

Max: "Richard? Richard something? Kennard"

Lincoln: "Richard Kennard"

Max: "Yeah Kennard"

Lincoln: "...it's a really cool framework for, basically you just point this tag at an Object or a bean and it runs through that bean and looks at all the properties and builds up an interface that shows up on the page."

Max: "Yeah, and in your JSF you just have one [line] and say this is the bean I want to do and it builds the UI. And it does it for... er... Swing, and..."

Lincoln: "You can do Swing, you can do GWT, you can do JavaFX I think. Lots of stuff."

Max: "So actually it is pretty powerful, but it's not..."

Lincoln: "The problem is then you've got this tag in there and it's... if you want to customize that then you're learning the Metawidget framework. And so what we are doing right now actually is we're customizing Metawidget so that, using the same inspection process that Metawidget provides, generate real code. Materializes it into real XML, real JSF pages. Then you can go in and modify those pages just like you would have done by yourself."

Listen to the full podcast here.

You Can't Spell Forge Without Metawidget

2011-12-19T09:30:00.014+11:00

JBoss have just released Beta 4 of JBoss Forge. There are a host of new features in this release. Most exciting for me being the new UI scaffolding.

Scaffolding has been significantly rewritten to use a new static Metawidget. This allows Forge to output pure JSF tags, with no runtime dependencies on any non-Java EE libraries. The UI includes creating, updating, deleting, pagination and searching. It also supports one-to-many, many-to-many, many-to-one and one-to-one relationships:

The code it generates is very clean:

<h:panelGrid columnClasses="label,component,required" columns="3"> <h:outputLabel for="customerBeanCustomerFirstName" value="First Name:"/> <h:panelGroup> <h:inputText id="customerBeanCustomerFirstName" value="#{customerBean.customer.firstName}"/> <h:message for="customerBeanCustomerFirstName" styleClass="error"/> </h:panelGroup> ...

Behind the scenes, Forge is still using the same Metawidget pipeline as before - the same Inspectors, WidgetBuilders, WidgetProcesors and Layouts. This means the scaffolding is pluggable to adapt to your needs - including custom UI libraries, custom layouts, even custom langauges (Ceylon, anyone?).

The new static Metawidget is also used to generate Java code for the JSF backing beans. Again using WidgetBuilders and outputting very clean code:

String firstName = this.search.getFirstName(); if (firstName != null && !"".equals(firstName)) { predicatesList.add(builder.like(root.<String>get("firstName"), '%' + firstName + '%')); } String lastName = this.search.getLastName(); if (lastName != null && !"".equals(lastName)) { predicatesList.add(builder.like(root.<String>get("lastName"), '%' + lastName + '%')); }

Please give it a try!

Download Forge Beta4

Install it

Run it

Copy and execute this command:
$ run-url https://raw.github.com/forge/core/master/showcase/posale.fsh

For the lazy, I've uploaded the project that Forge generates. You can download it here.

Pleasing Dick Wall

2011-12-04T19:25:00.005+11:00

In Episode 371 of the Java Posse, Dick Wall has this to say about D.R.Y. (at 47m.30s):

"That actually, I hate to say, but it's an affliction that's very very bad in the Java world. And you see developers drop it as soon as they see another programming environment and really grok the idea of Don't Repeat Yourself. A lot of the flagship libraries in Java are really bad for this.

Wicket is one that springs to mind... everybody loves Wicket, [but] now I've been exposed to a bunch of different stuff I look at it and you have to repeat things 3, 4 or 5 times sometimes. When you're adding a field on to a Web page you've gotta name it on the page and then you come into the code and you write your handle on it with the exact same kind of component that is, and the name, and even worse, you know, taking the current Java mindset of 'you should be working for the compiler' and not the other way around.

If you get it wrong, it complains at you. It doesn't try and fix it for you."

This is, of course, exactly the problem that Metawidget is designed to address. I talk about it in my JavaOne video here (at 5m.30s).

Unfortunately work has stalled on the Wicket version while I've been working on JBoss Forge integration. Wicket actually makes completely dynamic controls, like Metawidget, tricky because of its approach of 'a Java file and a static HTML file'.

However, I was fortunate to have lunch with Wicket guru Juliano Viana at JavaOne 2011. He deep dived into the Wicket internals and found MarkupContainer.getAssociatedMarkupStream for me. It looks like this can free up the requirement of a static HTML file. So hopefully there is a way to get around this Wicket limitation.

Metawidget @ JavaOne 2011: JBoss Booth Video

2011-12-01T12:58:00.015+11:00

JBoss have posted videos from sessions at their mini-theater in the JavaOne Exhibition Hall. This includes our talk on DRY UIs: Let the metadata do the work:

The video is available in High Definition, so please try the Full Screen mode if you find the coding examples difficult to read.

Should HTML.next Have A Higher Level of Abstraction?

2011-11-08T10:04:00.031+11:00

HTML brings a lot of great features to the table. One of them is device independence. The HTML author gets to write:

<button value="OK"/>

And the device gets to choose how to render that using a native widget:

I think this is a great level of abstraction. But in my opinion the W3C made a mistake when they specified:

<input type="checkbox"/>

See that type attribute? It's referring to the widget type. But it really should be referring to the data type. Then we could write:

<input type="boolean"/> <input type="date"/> <input type="integer"/> <input type="color"/>

And the device gets to choose how to render that. If it were a simple device, or it didn't understand the data type, it could just render a text box. But better implementations could offer nicer UIs. Date pickers. Spinners. Color pickers. Browsers could compete by offering better widgets.

Think how much time our industry has wasted re-implementing HTML date pickers and spinners. Hundreds of widget libraries across all development platforms (PHP libraries, Java libraries, .NET libraries, etc).

I came to this realisation while using Metawidget. Typically you tell Metawidget to generate an entire form, composed of many widgets:

<m:metawidget value="#{myForm}"/>

...which gives...

But I've found it suprisingly useful to still use Metawidget even when dealing with single widgets:

<m:metawidget value="#{myForm.name}"/> <m:metawidget value="#{myForm.age}"/> <m:metawidget value="#{myForm.dateOfBirth}"/>

Here we are deferring the actual widget choice to Metawidget. So Metawidget can choose it for us based on the best widgets available on the target device, our locale, our accessibility requirements etc. Maybe that's a plain text box. Or maybe it's a RichFaces date picker. Or an ExtGWT spinner.

It's nice to defer that choice, because now all the widgets can automatically upgrade over time as the platform improves. If this were in HTML too, it'd save an enormous amount of re-implementing. And it would provide a new battleground for browser competition.

Better for developers. Better for browser vendors. Better for consumers.

Metawidget Quotes

2011-10-30T21:06:00.005+11:00

A collection of quotes people have said about Metawidget:

"I finally had a chance to try out Metawidget on an example of my own and it is quite amazing"
Dan Allen (author, Seam In Action)

"Looks impressive... the author of this library has evidently put some real thought into this"
Michael Klaene (Java Developer)

"I spun up the SwingMetawidget, very impressive. Love the annotations, too. Thanks a lot for this API! I am going to try one of the web widgets next"
i k (Swing Developer)

"We have a large GWT app it could certainly do with this for the forms. The documentation looks very good. I also really like the 'don't take over the GUI' principle"
David Tinker (GWT Developer)

"This looks like a very interesting project!"
Johan Andries (Java Developer)

"I strongly agree that UI duplication is mindless, error-prone code that should have been solved years ago. I am so glad someone is addressing this"
Survey respondent

"On my todo list is to develop an integration with Metawidget. I'm impressed by the work they're doing here"
Dan Haywood (author, Domain-Driven Design using Naked Objects)

"Metawidget is worth taking a look at"
Eric Rich (Java Developer)

"I have taken a look at it, and found it's a wonderful tool. When coding with SWT, I always wanted to find such kind of tool..."
Zhong Nanhai (SWT Developer)

"Sounds impressive. I was infact looking for such a utility for a while"
Shashi Ayachitam (Java Developer)

"Developers no longer have to spend too much time to bind UI with POJO"
Vinay Saintantonyar (Java Developer)

"The strength of Metawidget is it allows the developer flexibility to change how the front-end is rendered because Metawidget does not exclusively own the front-end like many other frameworks"
Mark Ashworth (Java Developer)

"Metawidget is very interesting... I will try to use it in one of my projects"
Adam Bien (author, Oracle Java Developer of the Year)

"Think of a configurable form widget driven off of your beans through runtime inspection of properties, getters and setters, annotations, etc"
Dietrich Kappe (Java Developer)

"Our app has over 300 screens and UI duplication is a huge maintenance issue for us. You are definitely on to something here and I like the fact that your framework integrates with others and does not try to 'own' the UI"
Survey respondent

"I think Object Interface Mapper (OIM) is a very good 'concept' for this domain. I usually call it 'domain model framework' or something like that, but now I think OIM is more clear"
wangzx (Java Developer)

"In the past I used [other frameworks] but their approach is too invasive and unfittable. Metawidget is very flexible and integrates an environment already in production. Great great great framework!!!"
Nicola (Java Developer)

"Here's something different... it builds on your underlying framework and so is not competing with it"
Sachin (Java Developer)

"I have long held the reason for the incessant churn in how we best complete the UI architecture task is due to the continued quest for economic value. [Your work] shows there are benefits to separating the elements of that task from that churn"
Ed Burns (author, JSF specification lead)

"I have been using Metawidget (which is a really cool library by the way) on a project lately..."
Arthur Peters (Swing Developer)

"Metawidget not only provides a nice UI framework but offers realistically implemented connections to backends"
Fred Grott (Android Developer)

"It works, beautifully! Thanks for bringing us this powerful stuff
Phaderm (Swing Developer)

"Metawidget concept is the way to go.... you can exploit multiple UI targets with minimal code rewrite and take advantage of native widgets when required"
Steven Goldsmith (Java Developer)

"I'd like to thank you for what you've done with Metawidget. It's a really great framework and is proving especially useful in a model driven architecture we are implementing"
Ashlin Eldridge (Java Developer)

"Metawidget is a super-cool project"
Baruch Sadogursky (author, Spring in a Nutshell)

Metawidget @ JavaOne 2011 (Epilogue)

2011-10-10T10:26:00.010+11:00

I had a great time presenting Metawidget at JavaOne 2011. We had a good turn out (about sixty people) with lots of good questions at the end. My thanks to all who attended, and to my co-speaker Dan Allen.

The full talk should be available on Parleys in the next few weeks.

Metawidget @ JavaOne 2011 (Updated)

2011-09-13T11:40:00.029+10:00

The time and venue for the Metawidget technical session at JavaOne 2011 have now been confirmed:

DRY UIs: Let the metadata do the work
Date:	Wednesday 5th October 2011
Time:	1:00 PM
Speakers:	Dan Allen, Richard Kennard
Venue:	Parc 55 - Market Street
Length:	1 hour
Track:	Emerging Languages, Tools, and Techniques

How many times have you sat in a dark office after hours hand editing forms, page after page? Software teams spend a lot of time developing the UI. To speed up the process, developers resort to drag-and-drop widget solutions or model-based static generation tools. These approaches only change the appearance of the problem.

This talk presents Metawidget as a solution to keep your UIs DRY. Metawidget is a smart UI processor that populates itself, at runtime, with UI components that match properties of your model. Rather than introduce new technologies, it reads existing metadata (e.g. JavaBeans, annotations, XML) to create native UI widgets (e.g. JSF, Android, Swing).

Stop hand-coding your forms! Come learn how to break out of the rut!

I'll also be doing a supplemental session at the JBoss booth at 11.30am on Tuesday 4th, as well as being on-hand to answer questions and give live demonstrations.

My thanks to Lee Judaya who put together a cool looking promotional flyer for the sessions.

OIM: Metawidget v1.30

2011-08-30T10:15:00.003+10:00

Version 1.30 of Metawidget, the OIM is now available! This release includes the following enhancements:

This release contains breaking changes. We apologise for the disruption and provide this Metawidget 1.25 to 1.30 Migration Guide. Special thanks to George Gastaldi for his help with this release!

As always, the best place to start is the Reference Documentation:

http://metawidget.org/doc/reference/en/pdf/metawidget.pdf

Your continued feedback is invaluable to us. Please download it and let us know what you think.

What Good is an OIM?

2011-08-28T18:57:00.010+10:00

1. Introduction

Metawidget has coined the term Object User Interface Mapper (OIM). It's a new take on an old problem. Like any new approach, it can sometimes be difficult to identify where it can be applied. This blog entry outlines a number of use cases for an OIM, citing examples of real world implementations. In short, it helps answer the question: what good is an OIM?

2. Generate User Interfaces from Existing Business Objects

OIMs excel at generating widgets based on your existing UI framework, matched to your existing application business objects. Whether the application is a government tool for transaction processing or a pharmaceutical tool for database maintenance¹, OIMs are ideally suited (Figure 1).

One lead developer summarised: "Many frameworks or tools enforce the [tool] designer's vision on how solutions should be architected. What I liked about Metawidget is that I could drop it in whatever architecture I was using"¹. Another concluded: "In 10 years of software development, I can't count the number of times I've needed a simple form for users to enter or update data... no one has extended [a solution] in a general way to apply to a broad audience. Certainly there have been 'form code generators', but creating the form at runtime from metadata is a far more elegant approach in my opinion"¹.


Figure 1: Transaction processing and database maintenance

OIMs are less cumbersome than visual IDE designers such as NetBeans Matisse (Figure 2), or modelling languages such as Facelets. They require no repetitive definitions between UI and business objects. Such definitions are laborious to define and error-prone to maintain. OIMs are also more flexible than language-based tools such as Naked Objects. OIMs have an explicit focus on generating the same UI you would previously have coded by hand.

Figure 2: NetBeans Matisse

The introduction of an OIM can reduce the amount of repetitive, error-prone UI code in an architecture by up to 70%². One architect remarked: "it's a fairly established software engineering principle that the more you have to repeat something the higher the error is, the higher the chances there's going to be an error in the code"³. Another: "We had an experience in our last project, that a lot of view related bugs would come from missing required fields, wrong formatting and changing the model and not changing the view. Also, keeping those in synch, required a lot of effort, not complex, but we had most of our junior programmers dedicated to fixing those silly problems. [After we introduced Metawidget] it simplified a lot and this category of bug has simply disappeared"¹.

3. Generate User Interfaces from Unconventional Sources

Beyond conventional UI generation, the five characteristics of an OIM² allow it to generate UIs from arbitrary sources. This opens new possibilities for functionality.

The Telefónica Health Portal allowed users to describe portions of their required UI themselves, using a simplified Domain Specific Language. The generated portion was then inserted into the application dynamically, based on the logged in user's roles and permissions. The team reflected: "With our requirements Metawidget was basically the only option. Our usual techniques would not have done the job"⁴.

Another theatre system application exposed a plugin API that generated UIs for each plugin on-demand, at runtime. The team lead stressed: "One of the really important reasons I used Metawidget for this was that I have plug-ins that provide data objects for, and I/O support for, different types of [theatre] systems. I wanted to be able to just add [plug-ins] and have them be immediately editable without [them] needing to implement any UI code at all"¹.


Figure 3: Health application and theatre system

The ability of OIMs to inspect, and collate, metadata from arbitrary back-end sources permits a new level of dynamically generated UIs.

4. Generate User Interfaces with Consistent Behaviour

OIMs integrate with your existing back-end architecture, and deliver results integrated to your existing front-end framework. They provide a consistency of behaviour and layout across all the screens of your application. This goes far beyond traditional technologies such as CSS or Swing Look and Feels.

OIMs generate widgets at runtime from centralised code, ensuring: consistent choice of widgets for data types (i.e. date pickers for all dates, spinners for all integers); consistent insertion of validators and converters (i.e. for currency); consistent enforcing of data limits (i.e. minimum values for integers, maximum lengths for strings); and consistent layout of sub-entities (i.e. separated by section headings, or separated into tabs). UIs created by an OIM are more consistent and more robust than those created by hand. For example, few developers bother to put maxlength attributes on every one of their text fields: it is too laborious and likely to change over time, requiring error-prone maintenance. With an OIM, such limits are enforced automatically.


Figure 4: Superannuation application and ERP application

One ERP application (Figure 4) used Metawidget to ensure consistent behaviour across a large number of screens in a large team. The team remarked: "Metawidget is really useful in the way it is the foundation to build your solution... A great advantage [it offers] is UI standards. It is really hard to keep consistency, visual or functional standards when building UI in a large team. However when it is generated dynamically, the rules are centred and even the customisation is somehow controlled"¹.

5. A Platform for Adopting New Technologies

OIMs provide a common platform for technologies participating in UI development. Vendors can leverage this to lower the barrier of entry in adopting their technology, or to open their technology to a new market.

The Bean Validation plugin allows Metawidget to inspect Bean Validation annotations and translate them into UI data limits. This automatically allows Bean Validation to be applied to diverse UI frameworks including Swing, SWT, Spring and Java Server Faces.

The RichFaces plugin allows Metawidget to generate RichFaces components for arbitrary back-end architectures. This automatically allows RichFaces to bind to technologies such as Drools and jBPM. If an application is already using Metawidget, adding the RichFaces plugin will automatically upgrade every widget in the application across every screen to use rich UI widgets such as date pickers and spinners.

6. Conclusion

This blog entry has outlined a number of use cases for an OIM, and cited examples of real world implementations. We hope this will help you identify areas Metawidget could be used within your own applications. You can then apply the new approach of an OIM to the old problem of repetitive, error-prone UI code - saving both you and your organisation time and money.

References
Kennard, R. 2011, 'Adoption Studies'

Kennard, R. & Leaney, J. 2010, Towards a General Purpose Architecture for UI Generation. Journal of Systems and Software.

Kennard, R., Edmonds, E. & Leaney, J. 2009, Separation Anxiety: stresses of developing a modern day Separable User Interface. 2nd International Conference on Human System Interaction.

Kennard, R. 2011, 'Case Study: Telefónica Health Portal'

Metawidget 1.25 to 1.30 Migration Guide

2011-08-26T20:55:00.004+10:00

The next release of Metawidget (v1.30) contains some breaking changes. We apologise for the disruption and provide this Migration Guide to help in moving from v1.25 to v1.30. All of the existing documentation and examples have already been migrated, as a reference point.

Refactored InspectionResultProcessor

Inspired by this forum post, a suggestion by Dan Allen, and Kirill's advice we have refactored InspectionResultProcessors to reduce internal complexity. By adding 3 extra parameters to their interface...

String processInspectionResult( String inspectionResult, M metawidget, Object toInspect, String type, String... names );

...we can use them to consolidate other mechanisms. Specifically, we can:

remove FacesXmlInspector and simplify FacesInspector, replacing them with a FacesInspectionResultProcessor

remove JexlInspector and JexlXmlInspector, replacing them with a JexlInspectionResultProcessor

simplify JspInspector, replacing it with a JspInspectionResultProcessor

reduce our dependency on ThreadLocals (which can be brittle)

FacesInspectionResultProcessor, JexlInspectionResultProcessor and JspInspectionResultProcessor combine and extend the previous functionality of their Inspectors. Specifically they can now:

Evaluate expressions from arbitrary attributes. There is no longer any need for UiFacesAttribute, UiJexlAttribute or UiJspAttribute. You can just use UiAttribute directly:
@UiAttribute( name = LABEL, value = "#{person.readOnly ? 'Back' : 'Cancel'}" )

Even better, you can use UiLabel directly:
@UiLabel( "#{person.readOnly ? 'Back' : 'Cancel'}" )

Evaluate embedded expressions, such as:
@UiSection( "#{person.name}'s Details As At #{today}" )

Harmonized JSF EL

We took this opportunity to remove use of this in JSF EL expressions, in favour of _this. The former has been made a reserved word in EL 2.2 and beyond. You still declare injectThis in much the same way as before:

<facesInspectionResultProcessor xmlns="java:org.metawidget.inspectionresultprocessor.faces" config="FacesInspectionResultProcessorConfig"> <injectThis><javaBeanPropertyStyle refId="myPropertyStyle" /></injectThis> </facesInspectionResultProcessor>

Improved Proxy Support

The rise of dependency injection frameworks has made it increasingly common that the object Metawidget is inspecting is, in fact, a proxy. This is troublesome because many proxied classes do not maintain annotation and/or generics information. We've refactored the way we deal with proxies to support this. Specifically:

We've enhanced BaseXmlInspectorConfig.setRestrictAgainstObject so that XML-based inspectors can align with Object-based inspectors in the face of proxies. However this is disabled by default so you may need to enable setRestrictAgainstObject if you are mixing XML and Object-based inspectors in your app.
The inspectors no longer try and determine whether a class is a proxy by pattern matching its class name. Instead, they traverse up the class hierarchy. The API names have changed slightly to reflect this.

Again, we apologise for the disruption but believe these changes will help make Metawidget cleaner and more robust than ever before.

Metawidget Moving To GitHub

2011-08-23T12:08:00.014+10:00

After months of gentle nudging from folks like Greedy and Lincoln Baxter, and finally a big push from George Gastaldi, I'm thrilled to announce Metawidget has now made the move to GitHub.

The master repository is at https://github.com/metawidget/metawidget:

I'll be migrating all my internal tools over the next few days, and then it'll be social coding and pull requests ahoy!

My thanks to George, Lincoln and Greedy for their help.

Case Study: Telefónica Health Portal

2011-07-22T17:25:00.020+10:00

1. Introduction

This blog entry presents a case study of using Metawidget to provide automatic UI generation for the Telefónica Health Portal system. The Health Portal is a Web-based application designed around a Service Oriented Architecture and built using Google Web Toolkit. It serves the Spanish National Health System and is deployed to some 3,000 hospitals and health clinics across Spain. The integration of Metawidget allowed Telefónica to reduce development and ongoing maintenance costs. It further allowed the Health Portal to offer a level of flexibility and functionality not possible in previous products.

2. Organisation and Product Overview

Telefónica (LSE: TDE.L) is one of the largest fixed-line and mobile telecommunications companies in the world. It operates globally across Europe and Latin America with headquarters in Madrid, Spain (figure 1). Telefónica was founded in 1924, and was originally government owned until being privatised in 1997. Since then it has grown to over 260,000 employees with an annual revenue in excess of 60 billion Euros.

Figure 1: Telefónica headquarters in Madrid, Spain

The company was looking to develop a product for the Spanish National Health System (NHS). The Spanish NHS is similar to that found in many European countries. It consists of a network of health clinics and hospitals across different states and territories. Each centre employs multiple healthcare workers with an array of specialities including General Practitioners (GP), paediatricians and physiotherapists. They are funded through both public, government healthcare and private healthcare insurers.

The Telefónica Health Portal was to be an online platform providing a range of services to health clinics. The Health Portal's functionality would include administering a clinic (see figure 2) and scheduling physicians (see figure 3). Most relevant to this case study, the Health Portal could also serve as an intermediary between clinics and healthcare insurers. Such an intermediary would provide three key benefits compared to existing manual processes. First, it would provide interactivity: if additional documentation or authorisation codes were required during submission of an insurance claim, the insurer could request them at the time the claim was being lodged. Second, it would provide immediacy: after the claim was lodged, the Health Portal would report back a status such as approved, rejected or pending validation. Finally, it would improve processing times: claims could be lodged and payments made more quickly, and clinics could see real-time reports of settled payments against their accounts as they approached month end.

Figure 2: Health Portal administration

Figure 3: Health Portal scheduler

This description of the Health Portal, simplified for the purposes of this case study, is depicted visually in figure 4.

Figure 4: Simplified UML diagram of Health Portal

However, business analysis showed that the data needed in order to lodge a claim varied for each private healthcare insurer. Within each insurer, it further varied by speciality (GP, paediatrician, etc.). And within each speciality, it further varied by type of activity (initial consultation, follow-up visit etc.). The Health Portal would need one insurance claim form per insurer, per speciality and per activity. Worse, as new insurance companies signed on to the service, new forms would need to be developed. This ongoing development cost would threaten the economic viability of the Health Portal. Instead, Telefónica decided they needed a way to dynamically define portions of each insurance screen. Indeed, they wanted the insurer to be able to dynamically define their forms themselves. This was where Metawidget came in.

3. Integration of Metawidget

This case study interviewed members of the project team, including the project manager.

The discussion opened around the Health Portal's requirement to dynamically define portions of each insurance form. The project manager explained: "We had a need to dynamically create input data screens, we searched the different alternatives available in the market, and the one that fitted best was Metawidget". He explained they considered several alternatives but "after an exhaustive analysis of available tools we decided that the tool that best fitted our needs was Metawidget".

The Health Portal needed to provide a range of functionality. This required a rich UI with several different types of screens and aesthetics. There was no requirement to automatically generate the entire UI. Indeed for many screens doing so would have been impractical. For example figures 2 and 3 show screens that were manually tuned for usability. It would not have suited the project to impose a generic, stylized CRUD UI (or OOUI) across every screen. The team only wanted to use automatic generation for selected portions of their application. In addition, they had already chosen their preferred UI framework and tools (GWT 2011) and developed several screens using traditional techniques. It would not have suited them if the UI generator had tried to dictate their technology choices. Together, these observations validated Metawidget's approach to defining 'useful bounds' around UI generation (Kennard & Steele 2008).

The team wanted the dynamic portions of their insurance claim forms to be definable by the insurer. They built a UI to allow the insurer to specify their particular fields, including the name, data type and other metadata (such as whether they were optional fields). The team then needed these fields to be reflected on the clinic's screens. The application was built around a rich, Web-based UI making extensive use of JavaScript and client-side AJAX calls to Web services. The design was that, upon initiating an insurance claim, the UI would first invoke a Web service and supply the id of the insurer. The Web service would respond with an XML definition of the insurer's form requirements, including portions that described the dynamic fields. A typical response would be:

<?xml version="1.0" encoding="UTF-8"?> <mensaje co_op="R00210"> <R00210> <cif-aseguradora>00000000X</cif-aseguradora> <co-facturador>00000000X</co-facturador> <respuesta></respuesta> <timestamp>0000000000000000</timestamp> <agrupaciones> <agrupacion codigo="0001"> <nombre>AGRUPACION</nombre> <especialidades> <especialidad codigo="01"> <nombre>MEDICINA GENERAL</nombre> <actos> <acto codigo="0001"> <nombre>CONSULTA</nombre> <campos-variables> ...GP initial consult dynamic fields... </campos-variables> </acto> <acto codigo="0002"> <nombre>REVISION</nombre> <campos-variables> ...GP follow-up visit dynamic fields... </campos-variables> </acto> </actos> </especialidad> <especialidad codigo="02"> <nombre>PEDIATRIA</nombre> <actos> <acto codigo="0001"> <nombre>CONSULTA</nombre> <campos-variables> ...pediatrician initial consult dynamic fields... </campos-variables> </acto> <acto codigo="0002"> <nombre>REVISION</nombre> <campos-variables> ...pediatrician follow-up visit dynamic fields... </campos-variables> </acto> </actos> </especialidad> ...more especialidad... </especialidades> </agrupacion> ...more agrupacion... </agrupaciones> </R00210> </mensaje>

The UI generator would extract those portions of the XML response related to dynamic fields and use them to generate its UI. This requirement validated Metawidget's approach to performing generation at runtime. It is a scenario where a system's input is itself source code - adding new functionality and screens to an application. Runtime analysis is needed to accommodate such a scenario.

Because the fields were to be defined declaratively, visual IDE tools such as NetBeans Matisse were not applicable. And because the screens must be generated dynamically at runtime, rather than statically at development time, model-based tools such as JSF were not suitable either. What was needed was a runtime generator that could source its metadata from arbitrary sources, in this case embedded in an XML response from a web service. As the project manager commented: "The main feature [of Metawidget] for us was the possibility to dynamically, based on rules stored in our database [and exposed via a Web service], create input screens based on user selections". The team were able to plug in a custom inspector to suit their needs. But they did not require multiple inspectors, as the web service provided a single source of metadata, so they did not require collation. This validated Metawidget's approach to making collation pluggable via CompositeInspector.

Once the UI had been generated and the data captured, it was to be written back into the same XML structure and returned via a second web service. This was an interesting design decision. Its rationale was that there would then be a single piece of XML containing both field names, data types and values. This XML could be stored directly in the database. Screens using it could then be recreated and redisplayed at a later time, even if the insurer's original XML definition changed. For example if, having used the Health Portal for a few months, the insurer decided they needed to alter the fields on their form, the previous several months worth of claims and associated invoices could still be rendered in their original format. This was an unusual requirement because it meant the UI data was not to be stored back to a domain object. Indeed, there was no domain object to store back to. Rather, data values had to be read and written into a fragment of XML. The team were able to plug in a custom widget processor to achieve this, validating Metawidget's approach to pluggable processing.

Finally, the presentation of the dynamic portions was required to be different for different screens, so as to blend with the non-dynamic portions. For the 'lodge individual claim' and 'lodge multiple claims' screens a three column layout was required, as shown in figures 5 and 6. The bottom of each dialog box is generated by Metawidget. For the invoice screen a single column layout was preferred, as shown in figure 7. The centre of the dialog box is generated by Metawidget. These differences in layout validated Metawidget's approach to pluggable layouts.

Figure 5: Metawidget is used while lodging individual claims	Figure 6: Metawidget is used while lodging multiple claims
Figure 7: Metawidget is used while printing invoices

Having detailed the organisation and product, and understood Metawidget's integration within it, the case study turned to validating Metawidget's effectiveness.

4. Validation of Metawidget

This case study validated Metawidget against four themes.

The themes were derived from an overarching goal (GQM - Basili 1992) of Metawidget being a general purpose solution accepted by developers and applicable to industry. 'Acceptance' was considered a multi-faceted concern. First, a solution must have an obviousness to it: it must be approachable and straightforward to conceptualise, with a learning curve no steeper than necessary. Second, a solution should be convenient to use: it's API must be powerful but not cumbersome, and be more productive than developing the same application without it. Third, a solution must be adaptable: it must work well within a broad range of architectures, both front-end UI frameworks and back-end technologies. Finally, a solution must be performant: imposing reasonable processor time, bandwidth and memory constraints that do not outweigh its benefits.

Such themes can be tested either quantitatively or qualitatively. There is appeal in the former, as metrics such as 'number of lines of UI code saved', 'hours required to update the UI following changes to the domain model' or 'number of API methods necessary to implement a UI' have an impersonal, impartial character to them that conveys a sense of neutrality. However such thinking misses a critical point of Metawidget: its success is tied to the personal, to the partial. If Metawidget saves developers 25% of their UI code but they find it awkward and laborious to use, it will not achieve developer acceptance in significant numbers. If Metawidget can do more with fewer API calls but those calls are obtuse and inflexible, its long-term adoption in a project will be unlikely to survive handover from one developer to the next. If Metawidget can automatically update a UI in seconds, but that UI does not appear the way the designer intended, it will not pass usability tests.

Rather, a more reliable measure arises from qualitative metrics. Metrics such as developer thoughts, preferences, and satisfaction. It is possible to give these an impersonal, quantitative flavour using techniques such as Likert scales (1932), but again doing so risks losing a critical essence. Given the fragile, elusive nature of a quality such as 'acceptance', it seemed prudent this case study remain qualitative. The next sections discuss Metawidget in the context of the four themes.

4.1. Obviousness

Prior to encountering Metawidget did you have any preconceptions regarding UI generation? If so, how did Metawidget fit with those preconceptions? If not, could you identify with the gap Metawidget defines? One team member recalled: "In our case [it was] more than preconceptions. We had actual requirements. Requirements in concrete cases for generating UI, i.e. we needed a technology compatible with GWT, it had to work with XML, and it also had to be able to work dynamically". The team already had a product specification whose requirements included UI generation, so they were very clear about the gap they needed to fill.

The team member elaborated: "The Health Portal acts like a broker between insurance companies and clinics/hospitals. When data flows between those two parts (e.g. a clinic sends a bill to the insurance company), certain parts are common to all the insurance companies (such as the structure of worker's 'profiles' and of the medical 'acts') and others are not (bill numbering can be different, some include authorisation number etc.). We wanted the insurance companies to be able to define and provide (through XML) themselves these variable data for the benefit of both parties". The team understood this was not a requirement they could fulfil using their existing technologies. It was an explicit requirement for UI generation. This is unusual. It is distinct from a team who, say, were already using manual techniques to construct their UIs and were looking for a way to automate their processes.

As you were getting started with Metawidget, did you find its parts arranged roughly where you expected to find them? Were there any areas that stood out as being designed differently to you expected? If so, what were they and what were you expecting? The team member reflected: "we really didn't have so much expectation about that". Nevertheless, they were comfortable with what they found. The project manager confirmed: "The [Metawidget] concept makes sense, and it gives opportunities to create very flexible applications, where the input screens are easy to adapt to the user needs". Such input screens can be seen in figures 5, 6 and 7, described previously.

4.2. Convenience

Having determined what you wanted Metawidget to do, how difficult did you find getting Metawidget to do it? One team member responded: "Let's say the difficulty was medium. There were some features we wanted but which Metawidget did not have at that time, and that did require some customisation of the code". For these, the team were able to plug in their own inspectors and widget processors.

Were there scenarios where Metawidget demonstrated clear benefits over your usual techniques? The team member validated: "More than clear benefits. With our requirements Metawidget was basically the only option. Our usual techniques would not have done the job. The only other solution that came close to meet our requirements was TICBO [a Customer Relationship Management tool] but in end it did not meet all of them". Metawidget met all requirements because "it was compatible with GWT, could work with XML, and could work dynamically". This was a validation of Metawidget's mixture of useful bounds and runtime generation. They created a solution unlike any other available.

Were there scenarios where Metawidget was demonstrably worse than your usual techniques, or did not represent a compelling advantage? If so, what would have helped tip the balance? The project manager replied there were no demonstrably worse scenarios, but that "we think it would be nice to have conditional fields, so that [a field's] behaviour would depend on the user selections from other fields". Metawidget does support pluggable third-party expression languages for implementing conditional fields for different environments. However it did not cater for the particular combination of front-end and back-end this project chose. Specifically, Metawidget had no solution for client-side, browser-based (i.e. ECMAScript) conditional fields using GWT. More work was needed there, though there was good precedent for incorporating this kind of technology based on the other platforms.

4.3. Adaptability

How did you find Metawidget initially fit with your existing architecture? Were there parts that 'just worked'? The team member responded: "As [I said] before, the use of Metawidget was somewhat concrete and, where we used it, it did meet our requirements and worked. [On top of that] the code was customised to include features not yet present at the time". There were two examples of such customisation. The first was a custom inspector, CamposVariablesInspector. This was used to inspect fragments of the XML response returned by the insurer Web service, as shown in figure 8. This was different to Metawidget's standard inspectors, which generally inspected objects or whole XML configuration files.

Figure 8: Health Portal uses a custom inspector

The second piece of customisation was a custom widget processor, CamposVariablesBinding. This both extracted data values from the XML fragment and wrote them into the generated widgets, and also read them back from the generated widget and inserted them into the XML fragment, as shown in figure 9. Again this was different to Metawidget's standard binding, which bound data values to domain objects.

Figure 9: Health Portal uses a custom widget processor

Were there areas where you had to write your own plugins, and if so how did you find writing them? The project manager explained: "Being able to incorporate Metawidget within an existing UI was important. It's fundamental for our project". Similarly to integrate with their existing back-end: "It was important it supported our back-end. Being able to plug-in our back-end inspectors gave us the flexibility needed, it is impossible for Metawidget to support everyone's requirements". The inverse of this statement is that it is unrealistic to expect everyone to change their application to suit Metawidget's requirements. This ability to integrate was so important, in fact, that the project manager summarised "It was critical Metawidget supported both our front-end and back-end, otherwise we probably would not have even tried it [for the Health Portal]".

Were there areas where Metawidget couldn't be made to fit? The team member couldn't recall any: "No, where we used Metawidget it did fit".

4.4. Performance

How did your application compare, both in terms of speed and memory, before and after the introduction of Metawidget? The team member replied: "In this case there was no before and after. No alternatives to Metawidget were ever developed, it was included from the beginning". However the team had encountered no performance problems, having deployed the Health Portal to thousands of clinics across Spain.

Did you find the before and after reasonable in terms of the costs and benefits of UI generation? The team member opined: "As [I said] before, there were no alternatives developed. However, we consider the choice reasonable in terms of cost and benefits; it was really the only option that met our requirements. If not, these requirements would have had to be changed. That would have meant less flexibility to all the parties of the project. Of course, another option would have been to develop some in-house solution similar to what Metawidget does, but that was never really an option considering the costs and benefits". This validated that UI generation is conceptually a common problem (Kennard, Leaney & Edmonds 2009) that calls for a general purpose solution rather than an in-house one. "[It] did not add any business specific value if we could find a third-party solution that solved the same problem".

5. Conclusion

In closing, I asked the project manager how he would sum up the team's experiences with Metawidget? "Since we use [Metawidget] as a dynamic information capture tool, it gives us great flexibility towards fulfilling customer requirements in record time. Even more of the information captured is almost as a black box where our application does not apply any business rules, [letting] our customers [the insurers] be the ones that define the business rules. Our application is a bridge between the user and our customer, and from that point of view Metawidget fits our needs perfectly, since it allows us to offer the customer [insurer] with a tool for him to decide and customise, without our help, the information that needs to be captured from the user [clinic]".

This case study gathered responses that were pertinent to its qualitative metrics. In turn, these provided an understanding of its four themes and validated its goal. The case study found industry developers who had accepted, and successfully adopted, Metawidget for use in their application. At the time of writing, the Telefónica Health Portal has been in production for several months and deployed to some 3,000 health clinics across Spain. This presents strong validation of industry applicability and developer acceptance.

References

Basili, V. 1992, 'Software modeling and measurement: the Goal/Question/Metric paradigm'.
Kennard, R., Edmonds, E. & Leaney, J. 2009, Separation Anxiety: stresses of developing a modern day Separable User Interface. 2nd International Conference on Human System Interaction.
Kennard, R. & Steele, R. 2008, Application of Software Mining to Automatic User Interface Generation. 7th International Conference on Software Methodologies, Tools and Techniques.
Likert, R. A. 1932. 'A technique for the measurement of attitudes', Archives of Psychology, New York, No. 140.

Metawidget @ JavaOne 2011

2011-07-12T19:03:00.005+10:00

Metawidget has been accepted for a technical session at JavaOne 2011 (October 2nd-6th, San Francisco). My thanks to the selection committee and to Dan Allen for organizing this!

Here's the abstract:

DRY UIs: Let the metadata do the work

How many times have you sat in a dark office after hours hand editing forms, page after page? Software teams spend a lot of time developing the UI. To speed up the process, developers resort to drag-and-drop widget solutions or model-based static generation tools. These approaches only change the appearance of the problem.

This talk presents Metawidget as a solution to keep your UIs DRY. Metawidget is a smart UI processor that populates itself, at runtime, with UI components that match properties of your model. Rather than introduce new technologies, it reads existing metadata (e.g. JavaBeans, annotations, XML) to create native UI widgets (e.g. JSF, Android, Swing).

Stop hand-coding your forms! Come learn how to break out of the rut!

More details to follow as we get closer the time.

Metawidget 1.20 to 1.25 Migration Guide

2011-07-11T16:22:00.000+10:00

The next release of Metawidget (v1.25) contains some breaking changes. We apologise for the disruption and provide this Migration Guide to help in moving from v1.20 to v1.25. All of the existing documentation and examples have already been migrated, as a reference point.

Refactor dependencies for JSF, JSP, Spring and Struts annotations

This change only affects those projects using fine-grained Maven dependencies such as:

<dependency> <groupId>org.metawidget.modules</groupId> <artifactId>metawidget-annotation</artifactId> <version>1.25</version> </dependency> <dependency> <groupId>org.metawidget.modules</groupId> <artifactId>metawidget-beanvalidation</artifactId> <version>1.25</version> </dependency>

Projects using metawidget-all.jar are not affected.

We have refactored the annotation-based Inspectors from the metawidget-faces, metawidget-jsp, metawidget-spring and metawidget-struts modules into corresponding metawidget-facesannotation, metawidget-jspannotation, metawidget-springannotation and metawidget-strutsannotation modules respectively. You will need to update your pom.xml to add in these new dependencies.

This was done for two reasons:

Most importantly, application environments where the Web tier is separated from the business tier may need the annotations to be deployed on the back-end and the UI widgets deployed on the front-end. Some frameworks and application servers have classpath issues if the two are not deployed separately.
Build environments like m2eclipse do not properly support mixing JDK 1.4 and Java 5 targets in the same source tree, so separating them removes a hack we were using (Metawidget tries to target JDK 1.4 wherever possible).

Similarly, we have separated the Java 6-specific metawidget-grouplayout from the JDK 1.4-compatible metawidget-swing.

Again, we apologise for the disruption. Feedback welcome!

Extend Your Wi-Fi The Easy Way: No Configuration Required

2011-07-05T13:47:00.016+10:00

The proliferation of Wi-Fi enabled devices around my home (phones, tablet, games console) finally drove me to doing something about my Wi-Fi reception. Like most people my modem is under a desk in a corner of the house. The Wi-Fi router is beside it, and looks like this:Predictably Wi-Fi reception drops rapidly towards the back of the house. I looked into getting a Wi-Fi Extender like this:

But apparently they can be tricky to configure. I also looked into a second Wi-Fi router, but I assume then you have two Wi-Fi hotspots? And have to configure your devices to connect to both? Icky.

Then something occurred to me. See those 3 antennas on the back of the router? What are they doing exactly? I assume they're all receiving in a spherical (or perhaps conical) space, but seeing as all 3 are stuck under my desk they're not achieving much. I noticed they unscrew easily and you can buy a coaxial cable like this...

...from online stores like rfshop.com.au. Specifications are:

Connector 1	RP SMA Plug (Female pin)
Connector 2	RP SMA Jack (Male pin)
Cable Type	240 series
Length	10 metres
Ohms	50 ohm (TV coaxial is 75 ohm)

So I ran one of the antenna up into the roof cavity and guess what? Now I get great Wi-Fi reception, even out in the garden! I still have only one Wi-Fi hotspot, and there was no configuration required. A bit unconventional, perhaps, but an idea for all you Do-It-Yourself-ers out there.

3 Out Of 4 Developers Could Benefit From Metawidget

2011-06-24T15:08:00.015+10:00

I thought it was about time I posted the 'results to date' of the Metawidget survey I've been running.

I started the survey in response to the query 'just how prevelant is the problem of duplication in User Interface development?' By 'duplication' I mean code that you have to write, but that could be inferred using existing sources within your application. For example the maximum length of a UI text box could be inferred from a database schema; the correct format for an e-mail address could be inferred from a validation subsystem; the available navigation buttons could be inferred from a BPM engine. Such duplicated values must be declared identically, and must be kept identical throughout your project's lifetime. If they diverge, for example if the UI allows text to be input that is longer that the database can store, it's likely to cause an error.

So how many developers have to do this error-prone sort of work, duplicating information throughout their applications? Apparently 3 out of 4. Every time they add a new field to their back-end, they also need to:

This lends weight to the idea that a project like Metawidget has the potential to help a great many developers. I've previously blogged a more in-depth discussion on the problem of duplication in User Interfaces. The survey is still open, so please submit your votes!

iPad vs Android: Do Consumers Really Want Flash?

2011-06-20T16:24:00.005+10:00

Say what you will about Apple not supporting Flash, consumer choice, and all that. But I know one thing: it completely rocks that I can run ABC Reading Eggs as a full-screen Flash game on my Asus Eee Pad Transformer:

Now the kids can play it comfortably on the couch instead of stuck at a desk in the study! Android FTW!

Price Gouging and the Asus Eee Pad Transformer

2011-06-17T13:58:00.005+10:00

A few months ago Australian retailers (perhaps buoyed by the spectacular success of the Minining Industry doing a similar thing) tried to lobby the government to add Goods and Sales Tax (10%) to overseas (i.e. online) purchases. They cited the usual "if we're hurting, we can't create as many jobs, and so everybody suffers".

Personally I enjoy supporting local retailers. I like brick and mortar stores. I like being sold to by an enthusiastic and informed sales person. And I like the comfort of knowing I can return a product and have my warranty serviced locally.

I like all of this more than 10%. But not more than 36%.

Recently I wanted to buy an Asus Eee Pad Transformer so I could test Metawidget on a physical tablet. The Transformer is a great product at a great price: $399 USD for the base model, $149 USD for the keyboard add-on. So with the way the Aussie dollar is at the moment I figure that should be about $550 AUD, right? Wrong.

The best I could find locally was $750 AUD. That's a 36% difference! So instead I got it from Amazon.com for $570 AUD including international delivery. A good $180 cheaper than I could buy it locally. It's a little hard to find in stock at the moment, but http://nowinstock.net took care of that.

So yes, it comes with a U.S. plug which I'd rather not have. And yes, I'll have to ship it Stateside if anything goes wrong with it. And yes, I wish I could buy it locally at a price I felt wasn't price gouging. But I simply can't.

HornetQ: I Want My... I Want My... I Want My MTV (um, JBM)

2011-06-16T11:31:00.001+10:00

(with apologies to Dire Straits)

Following on from my previous two posts I've been wrapping up my migration from JBoss 5.1.0.GA (which used JBoss Messaging (JBM)) to JBoss AS 6.0.0.Final (which uses HornetQ). As I said before the end result is well worth it: HornetQ is very fast. But I've hit a few gotchas.

8. Uneven Nodes

With JBM (and most messaging implementations) the 'natural' thing to do (i.e. if you're not thinking too hard) is store your JMS queue in a relational database. Then all your nodes consume off that single queue. Some disadvantages of this approach are: your database is a Single Point of Failure; relational databases aren't great for implementing high performance queues.

HornetQ doesn't support relational databases at all. Instead all queues are stored directly on the local file system. And you mustn't share that file system. So now the 'natural' thing (i.e. again, if you're not thinking too hard) is for each node to have its own 'slice' of the overall queue.

This change in the 'natural' order of things has a side effect. With JBM, your nodes would naturally consume off the overall queue as quickly as possible. With HornetQ, they only ever naturally consume off their slice of the queue. If, like us, you have grown your cluster over time and some of your nodes are on better spec hardware than others (more RAM, more CPU cores etc) this is a problem. Because your overall queue processing time will be limited to the time it takes the slowest node to finish its slice.

Really what you need is for HornetQ to either: at distribution time, give more messages to the fast nodes and fewer messages to the slow nodes. Or, at consumption time, redistribute messages from the slow nodes whenever the queues on the fast nodes are empty. HornetQ doesn't support either of these features yet (RFE here).

In the meantime, HornetQ can support the 'old JBM model' of a single queue. This is covered (in a slightly outdated JBoss 5 way) under 32.5. Configuring the JBoss Application Server to connect to Remote HornetQ Server. Basically you need to:

On all nodes, modify /server/all/deploy/jms-ra.rar/META-INF/ra.xml to use NettyConnectorFactory (instead of InVMConnectorFactory) and supply a host and port (this is your MDB consumer):

<resourceadapter> <resourceadapter-class>org.hornetq.ra.HornetQResourceAdapter</resourceadapter-class> <config-property> <description>The transport type</description> <config-property-name>ConnectorClassName</config-property-name> <config-property-type>java.lang.String</config-property-type> <config-property-value>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</config-property-value> </config-property> <config-property> <description>The transport configuration. These values must be in the form of key=val;key=val;</description> <config-property-name>ConnectionParameters</config-property-name> <config-property-type>java.lang.String</config-property-type> <config-property-value>host=${node.with.queue:localhost};port=${hornetq.remoting.netty.port:5445}</config-property-value> </config-property></tt>

On all nodes, modify /server/all/deploy/hornetq/jms-ds.xml to use NettyConnectorFactory (instead of InVMConnectorFactory implicitly) and supply a host and port (this is your producer):

<tx-connection-factory> <jndi-name>JmsXA</jndi-name> <xa-transaction/> <rar-name>jms-ra.rar</rar-name> <connection-definition>org.hornetq.ra.HornetQRAConnectionFactory</connection-definition> <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property> <config-property name="ConnectorClassName" type="java.lang.String">org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</config-property> <config-property name="ConnectionParameters" type="java.lang.String">host=${node.with.queue:localhost};port=${hornetq.remoting.netty.port:5445}</config-property>

On all nodes, pass the same -Dnode.with.queue=192.xx.xx.xx value

Now the MDBs on all nodes will both produce to, and consume from, node.with.queue. You're back to a Single Point of Failure but you're also back to supporting 'uneven' nodes (i.e. some faster than others). In addition may I suggest, in hornetq-configuration.xml:

Set <clustered>false</clustered>

Remove all <connectors />

Leave just the Netty <acceptor />

Remove all <broadcast-groups />

Remove all <discovery-groups />

Remove all <cluster-connections />

Remove your cluster username/password

Because now you're no longer using any clustering (at the HornetQ level) so can remove that overhead.

Hope that helps somebody!

Stung by HornetQ: The Revenge

2011-06-14T11:09:00.005+10:00

Following on from my previous post I've been spending some more time with HornetQ and have discovered a few more gotchas:

4. Stuck By Default

There's some advice here that says...

"Probably the most common messaging anti-pattern we see is users who create a new connection/session/producer for every message they send or every message they consume. This is a poor use of resources... Always re-use them"

...couple that with other advice that says...

"Please note the default value for address-full-policy [when the send buffer is full] is to PAGE [out to disk]"

And you might think the Right Thing To Do is set up a single connection/session/producer and send all your messages to the queue. But if you're doing this in a transaction (most Web applications are) you'd be wrong. Why? Because there's some conflicting advice that says...

"By default, HornetQ does not page messages - this must be explicitly configured to activate it"

And a setting in the JBoss/HornetQ integration (hornetq-configuration.xml) that says...

<max-size-bytes>10485760</max-size-bytes> <address-full-policy>BLOCK</address-full-policy>

So by default JBoss will get stuck if you try sending more than 10MB of messages in a single transacted producer (ie. before your MDBs can start consuming them). 10MB is not a lot. For me it was about 1,000 messages of about 5,000 characters each (a Unicode XML string).

Here are my suggestions:

HornetQ should treat its JBoss JMS integration as more of a first class citizen. It should be a primary use case, rather than relegated to a chapter at the back of the user guide. Why? Because most people that just dip into the User Guide are going to be doing so from a JBoss JMS mindset. So if you say something like "Please note the default value is to PAGE" then you need to also say, immediately afterwards, " (except on JBoss where the default value is to BLOCK)"

BLOCKing is a poor default value. Either make it fail (so the user gets an error) or make it PAGE (so the user gets an error when their disk is full). At least then the developer knows where to look. But blocking just results in the queue being 'stuck' - with no clue to the developer who has barely heard of their underlying JMS implementation, let alone blocking versus paging and <address-full-policy>

5. Stuck By Bugs

HornetQ is pretty new and there are a few bugs that can cause your JMS messages to get stuck. There's the fact that MDBs will rollback/retry indefinitely, that messages with different JMS priorities may get forgotten, that messages can be forwarded to dead cluster nodes.

When you have several different bugs interacting to produce an overall symptom (ie. a stuck queue) it can be very hard to separate them to understand their underlying causes. This causes a lot of pain!

6. Stuck By Birth

This one isn't really HornetQ's fault, but its behaviour seems different to JBoss Messaging. If your MDB uses @EJB injection you really need to setup <depends ... > blocks in your jboss.xml...

<message-driven> <ejb-name>LongRunningProcessConsumerBean</ejb-name> <destination-jndi-name>queue/avant-ss.long-running-processes</destination-jndi-name>  <depends>jboss.j2ee:ear=avant-ss-app.ear,jar=avant-ss-dev-ejb.jar,name=LongRunningProcessBean,service=EJB3</depends> <depends>jboss.j2ee:ear=avant-ss-app.ear,jar=avant-ss-dev-ejb.jar,name=BusinessRulesBean,service=EJB3</depends></message-driven>

...because HornetQ starts up and starts consuming very early. This is particularly bad because these errors go quietly into the boot.log, not the regular system.log, so you don't realise that your MDBs crashed on startup.

Oracle and the Evil Alternative: Taking Java Private

2011-06-03T09:53:00.019+10:00

In a recent episode of the Java Spotlight Podcast, Henrik Ståhl (Oracle's Senior Product Director of Java Platform Development) is interviewed about Oracle's strategy for Java past and present.

At 9 minutes 20 seconds he says "[Oracle] looked at the evil alternative, taking Java private". He then goes on to say "we determined it wasn't a good idea". But I was interested that Henrik didn't say "we determined it wasn't possible".

I contacted Henrik and asked for clarification: how would 'taking Java private' work?

Relax, This Isn't Going To Happen

First, let's be clear. Henrik has been explicit about Oracle's strategy for Java (here, here, here and here): they have considered this evil alternative and rejected it. That's not what this blog is about. Let's not start a FUD storm.

Rather I'm interested in how any company could, even hypothetically, take a GPL'd project private.

So, Hypothetically, How Would It Work?

Henrik explained the basic idea was that, given Oracle owns or co-owns all OpenJDK Intellectual Property (IP), they
have the right to release it under a non-GPL license. The owner of the IP can retroactively apply any license he/she wants, provided all prior modifications to the IP were made by that same owner. This appears to sidestep the GPL copyleft clause.

Of course you can't stop the community using the existing GPL'd version. Nor can you stop them forking it (though under a different name). But being able to un-GPL the code is a significant leg up from, say, having to build a clean room implementation before you can privatize it. It means you can have a 100% compatible, closed source product from day one, built using modified GPL'd code. And I assume if you rev the versions quick enough, most corporates will follow you rather than wait for the community version to catch up. Effectively you can close source a GPL project.

So my question is: is this legitimate? Can a corporation take a piece of Open Source software, acquire all IP rights to it, then close source its future versions? Is this a risk of relying on Open Source software? Should steps be taken to mitigate this risk? For example, should an Open Source project ensure its IP is distributed between multiple neutral entities (and avoid having Contributor Agreements that require handing over IP rights)?

Stung by HornetQ

2011-06-01T15:42:00.008+10:00

I've recently been upgrading our JBoss 5.1.0.GA and JBoss Messaging based application to JBoss 6.0.0.Final and HornetQ. The end result has been positive: HornetQ is very fast. But there were a few gotchas I thought I'd share:

1. No More Database, Lots More Backups

HornetQ eschews the JBoss Messaging approach of storing messages in a shared database. Instead it uses the file system directly (and, on Linux, accelerated AIO). But note this doesn't mean a shared file system. It means each cluster node has its own file system, with peer-to-peer communication to distribute messages between them.

The advantage of this approach is you no longer have a Single Point of Failure (ie. the database). But it's quite a shift in mindset if you're used to thinking of your database as a heavy, fault-tolerant kind-of-thing and your nodes as lightweight, throwaway kind-of-things. Because now, each node stores a portion of your messages. So if you lose a node you lose some messages.

The recommended solution to this is to have backup nodes. Whereas before you might have one big backup instance for your database, and no backups for your nodes, now you need a backup for each node. See this forum thread. Confusingly, when talking about backup nodes you may choose to use a shared file. But this is only for sharing between the 'backup' and 'live' instance of a single node.

2. hornetq-jms.xml Is A Red Herring

Out of the box, JBoss 6.0.0.Final includes a server/all/deploy/hornetq/hornetq-jms.xml that looks like this:

To my mind this is very confusing, because if you're using JMS producers and MDBs all those <connection-factory> configurations aren't used! I would recommend deleting them, for 3 reasons:

You see the /ConnectionFactory JNDI reference in there and think you should start using ic.lookup("/ConnectionFactory") in your code. If you do, you'll get non-transacted queue sessions, duplicated messages, lost messages, and all sorts of other weirdness. Stick with ic.lookup("java:JmsXA")

If using java:JmsXA, those <connection-factory> configurations don't apply! You need to look instead in server/all/deploy/hornetq/jms-ds.xml. This is using InVMConnectorFactory implicitly, but you can explicitly configure it

If using MDBs, again those <connection-factory> configurations don't apply! MDBs are configured in server/all/deploy/jms-ra.rar/META-INF/ra.xml. They use InVMConnectorFactory by default.

This last point is a real doozey. Because if you want to simulate a heavyweight store of messages with lightweight consumers who read from it (like JBoss Messaging) you're going to want to use <consumer-window-size>0</consumer-window-size>. You'll find lots of examples on the Web of putting this in hornetq-jms.xml. But consumer-window-size won't work there, because MDBs don't use hornetq-jms.xml. Instead you need this in ra.xml:

<config-property> <description>The consumer window size</description> <config-property-name>ConsumerWindowSize</config-property-name> <config-property-type>java.lang.Integer</config-property-type> <config-property-value>0</config-property-value> </config-property>

3. hornetq-configuration.xml Is Noisy

I'm a 'break it to learn it' kind of guy. So to my mind the connectors and acceptors section of hornetq-configuration.xml is a bit noisy. Here's what you can reduce it to:

<connectors>  <connector name="netty"> <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class> <param key="host" value="${jboss.bind.address:localhost}"/> <param key="port" value="${hornetq.remoting.netty.port:5445}"/> </connector> </connectors> <acceptors>  <acceptor name="netty"> <factory-class>org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class> <param key="host" value="${jboss.bind.address:localhost}"/> <param key="port" value="${hornetq.remoting.netty.port:5445}"/> </acceptor>  <acceptor name="in-vm"> <factory-class>org.hornetq.core.remoting.impl.invm.InVMAcceptorFactory</factory-class> <param key="server-id" value="0"/> </acceptor> </acceptors>

Your Mileage May Vary

Of course, these tips aren't for everyone. But if you're like me they may save you a few hours banging your head against the desk!

Is There Convergence in the Field of UI Generation?

2011-05-20T21:29:00.016+10:00

Kennard, R. & Leaney, J. 2011, Journal of Systems and Software

Abstract

For many software projects, the construction of the User Interface (UI) consumes a significant proportion of their development time. Any degree of automation in this area therefore has clear benefits. But it is difficult to achieve such automation in a way that will be widely adopted by industry because of the diversity of UIs, software architectures, platforms and development environments. In a previous article, the authors identified five key characteristics any UI generator would need in order to address this diversity. We asserted that, without these characteristics, a UI generator should not expect wide industry adoption or standardisation. We supported this assertion with evidence from industry adoption studies. A further source of validation would be to see if other research teams, who were also conducting industry field trials, were independently converging on this same set of characteristics. Conversely, it would be instructive if they were found to be converging on a different set of characteristics. In this article, the authors look for such evidence of convergence by interviewing the team behind one of the research community's most significant UI generators: Naked Objects. We observe strong signs of convergence, which we believe signal the beginning of a general purpose architecture for UI generation, one that both industry and the research community could standardise upon.

1. Introduction

For many software projects, the construction of the User Interface (UI) consumes a significant proportion of their development time. Research in the early 1990s found that some 48% of application code and 50% of application time was devoted to implementing UIs (Myers 1992). These figures are still considered relevant today, more so with the increased demands of richly graphical and web-based UIs (Jha 2005; Daniel et al. 2007), therefore any degree of automation in this area has clear benefits. But it is difficult to achieve such automation in a way that is useful and widely adopted by industry. In previous papers (Kennard & Steele 2008; Kennard, Edmonds & Leaney 2009) the authors explored the diversity of UIs, architectures, platforms and development environments that contribute to this difficulty. And in a recent article (Kennard & Leaney 2010) the authors identified five key characteristics any UI generator would need in order to address this diversity. The authors asserted that, without these five characteristics, a UI generator should not expect wide industry adoption or standardisation. We summarised these five characteristics as:

Inspecting existing, heterogeneous back-end architectures: the authors found many business systems are modelled using what Fowler (2002) calls "anaemic entities". These are surrounded in an arrangement that Firesmith (1996) describes as "dumb entity objects controlled by a number of controller objects". Such controller objects include persistence contexts, validation subsystems and Business Process Modelling (BPM) languages. As far as UI generation is concerned, there is a single source of truth (SSOT) but it is decentralised amongst these multiple subsystems. As Shan et al. (2006) enumerate, there are often competing implementations of the same subsystem. Furthermore as Rouvellou et al. (1999) shows, different types of subsystems become popular over time, such as rule engines. Any UI generator that seeks to dictate, rather than adapt to, a system's architecture therefore has limited practical value.

Appreciating different practices in applying inspection results: adoption studies (Kennard & Leaney 2010) showed the raw inspection result invariably needs post processing before it is suitable for consumption by a UI generator. For example, fields generally need to be arranged in a business defined order, or excluded based on business defined criteria. In some cases this processing can be performed independent of any particular UI screen. For example, globally excluding fields that represent database synthetic keys. In other cases it requires knowledge of which UI screen the user has navigated to. For example, a summary screen versus a detail screen. Furthermore, different practitioners had different preferences on how to perform such post processing. Some preferred a 'comes after' approach, whereby each business field can specify the field that immediately precedes it. But some adoption studies reported "I would rather give the properties priorities so that I can say 'this one comes first' instead of 'this one comes after that other one'. It's just more natural to me".

Recognising multiple, and mixtures of, UI widget libraries: practitioners discussed how industry UI libraries were diverging from any notion of a single, ubiquitous UI framework. They expressed the need to support a variety of front-end frameworks, including third-party and in-house widget libraries. In particular, they talked about the need to mix multiple third-party and in-house widget libraries within the same UI, in order to achieve a high quality user experience. Any UI generator that limits this choice compromises usability - the most determining factor of a UI - for the sake of automatic generation.

Supporting multiple, and mixtures of, UI adornments: in raw form, a widget is unlikely to be suitable for inclusion in a UI. For example, end users interacting with a raw text field are able to enter arbitrary text. However the business requirement may be for, say, a credit card number. Widgets therefore need to be further adorned with data validators, data binding frameworks and event handlers. Of particular note is that some of these mechanisms, such as a credit card validator, may come from a different third-party library than the raw widget.

Applying multiple, and mixtures of, UI layouts: a final characteristic was supporting multiple ways to arrange widgets on the screen. It significantly detracts from the practicality of automated generation if it in any way compromises the final product in usability, or even in aesthetics (Myers, Hudson & Pausch 2000, p. 13). Yet there is a formidable degree of variability. Fields may typically be arranged in a 'column', with the widget on the right and its label on the left. But other times the practitioner may want two or three such columns side by side. If so, they may need some widgets - such as large text areas - to span multiple columns. Or they may abandon columns altogether and want the fields arranged in a single, horizontal row. Furthermore, it is not difficult to posit other real world arrangements, such as right-to-left arrangements for the Arabic world. It is important to accommodate this variety if the generator is to achieve the exact look the practitioner desires.

Having defined these five characteristics, the authors supported them with evidence from industry adoption studies (Kennard & Leaney 2010). A further source of validation would be to see if other research teams, who were also conducting industry field trials, were independently converging on this same set of characteristics. If they were as fundamental as we believed, other teams should have been identifying similar constructs. Conversely, if they were found to be converging on a different set of characteristics, that would also be very instructive. In this article, the authors look for such evidence of convergence by interviewing the team behind one of the research community's most significant UI generators: Naked Objects. Clearly this is a qualitative measure, not quantitative, but has validity in conjunction with our previous work (Kennard & Leaney 2010) as a triangulation between industry and the research community.

2. Related Work

Research in the field of UI generation dates back over two decades. Projects including, though by no means limited to, COUSIN (Hayes, Szekely & Lerner 1985), TRIDENT (Bodart et al. 1995), UsiXML (Vanderdonckt et al. 2004), OliviaNOVA and OOWS (Valverd et al. 2006) and AUI (Xudong & Jiancheng 2007) have all explored a variety of techniques. The work was given increased urgency with the emergence of ubiquitous computing (Weiser 1993) and its proliferation of different UI devices with widely varying capabilities.

However most approaches have not taken industry acceptance and adoption as a key driver for their work. This means they have tended to exhibit significant disadvantages from an industry perspective (Myers, Hudson & Pausch 2000). Many require developers laboriously restate information that is already encoded elsewhere in an application. "A common disadvantage of both [interactive graphical editing tools and UI modelling languages] is the fact that the user interface is defined explicitly and separately" (Jelinek & Slavik 2004). This makes them a source of errors should the application code and the UI model not stay synchronised. Other UI generation approaches have imposed generalised interfaces which appear quite differently from, and function less effectively than, those designed with consideration to their specific purpose (Falb et al. 2007). Such disadvantages have led to limited adoption of these tools within industry.

There have been some notable industry successes, however. The Cameleon reference framework (Calvary et al. 2003) defines a Unifying Reference Framework for diverse, ubiquitous devices. The team have worked closely with the World Wide Web Consortium (W3C) with a view to industry standardization. Cameleon introduces "the notions of multi-targeting and plasticity" and "serves as a reference for classifying user interfaces supporting multiple targets, or multiple contexts of use in the field of context-aware computing". It further incorporates UsiXML (Vanderdonckt et al. 2004), a common User Interface Description Language (UIDL), which has also been submitted to the W3C for standardization. In doing so, it hopes to address a shortcoming of "AUIML, UIML, XAML, XIML, XUL" in that they "result in many XML-compliant dialects that are not (yet) largely used and that do not allow interoperability between tools that have been developed around the[ir own] UIDL".

As an approach gains acceptance and adoption within industry it generally inspires multiple implementations. These implementations first compete, then converge on a set of core characteristics with some additional features as a differentiator. This convergence ultimately leads industry to standardize upon the core characteristics, reflecting a pivotal moment in the maturity of the approach. This industry convergence can be evidenced in such projects as Hibernate and TopLink standardizing under JPA, and Spring, Guice and Seam standardizing under JSR 330.

Convergence, therefore, requires the experience and validation that come from large scale adoption. One approach that has seen significant adoption, being used by large organisations such as the Irish Department of Social Protection and deployed to thousands of users, is the Naked Objects pattern (Pawson 2004). Given the authors' focus on industry applicability, Naked Objects presents as a forerunner in bridging the divide between the theoretical and the practical.

The naked objects pattern considers "an application solely in terms of the [domain] objects. These objects are then rendered directly visible to the user by means of a generic presentation layer. The user undertakes all tasks by directly invoking methods on those [domain] objects. This approach has been dubbed ‘naked objects’, because as far as the user is concerned he or she is viewing and manipulating the ‘naked’ business domain objects". If there is any doubt as to the significance of Pawson's approach, one need look no further than the polarising effect it has had on the research community. It has been lauded by renowned pioneers such as Trygve Reenskaug, inventor of the Model-View-Controller (MVC) pattern: "In the quarter century since the inception of MVC, there has been little progress in empowering the users. This is where Pawson’s work comes as a fresh contribution in an otherwise drab market... Naked Objects represent a new beginning pointing towards a novel generation of human-centred information systems" (Pawson 2004, p. 3). It has been similarly praised by Dave Thomas, co-author of The Agile Manifesto: "Naked Objects is the embodiment of the Agile movement: lean, elegant, user-focused, and with testing built right in. Reduce a problem to its bare essentials, code it up with no extra fluff, then ship it out. Naked Objects brings programming back to its real purpose: expressing and solving business problems" (Pawson & Matthews 2002). But the Naked Objects pattern has also been derided by equally renowned pioneers such as Larry Constantine, expert in usage centred design: "The usability problems with [Naked Objects] interfaces under most conditions are too numerous to go into... Pawson and [framework implementer Robert] Matthews, who by their own admission are neither usability experts nor well-versed in user interface design, seem to be blissfully ignorant of the problems... Their book cites sources arguing for 'object oriented user interfaces' but ignores the critical literature that long ago discredited the concept" (Constantine 2002).

The authors, too, have been critical of Naked Objects. When developing our own UI generator, called Metawidget, we have expressed doubts over the practicality of the Naked Objects 'behaviourally-complete' methodology. This methodology dictates "all the functionality associated with a given entity [must be] encapsulated in that entity, rather than being provided in the form of external functional procedures that act upon the entities" (Pawson 2004). Yet Pawson himself recognises "most object-oriented designs, and especially object-oriented designs for business systems, do not match this ideal of behavioural-completeness". The authors believe this is not, as Pawson suggests, because they are poorly designed. Rather, they are seeking to leverage functionality provided by the large number of mature subsystems available in industry, in order to increase productivity and reduce development cost (Kennard & Leaney 2010). For Naked Objects to be applicable to such business systems, it needs to accommodate their approach rather than expect them to be re-architected as behaviourally-complete.

However, all such criticisms are levelled at the version of Naked Objects last described by the academic literature (Pawson 2004). Like any good software project, Naked Objects has evolved over the intervening years. The team now have both Java and .NET implementations, have published several books (Pawson & Matthews 2002; Haywood 2009), and have continued to refine their approach. They have recently moved to standardise and increase adoption by moving Naked Objects for Java to the Apache Software Foundation under the name Apache Isis. The frameworks implementing the naked objects pattern in 2010 have many differences to the original Naked Objects Framework of 2004.

The authors contacted the Naked Objects team for an update on their work. What we discovered was a surprising amount of independent convergence with our own ideas.

3. Methodology

The authors interviewed Dan Haywood over a series of e-mails in late 2010. Dan is a UK-based freelance consultant specialising in enterprise application development using domain driven design approaches and agile development. He is the project lead on the Apache Isis project (the effort to standard Naked Objects within the Apache Software Foundation), the author of Domain Driven Design using Naked Objects and a long-time advocate of the naked objects pattern.

We chose a standardized, open-ended format for the interview (Valenzuela & Shrivastava 2002). This approach involves asking broadly framed questions to allow the candidate room to talk openly, avoiding leading the interviewee and therefore minimizing bias. The overarching theme of the interview was the current feature set of the Naked Objects architecture. The interviewee was asked to discuss, and contextualize, aspects of their approach. The goal was to draw out decisions underlying the original design and motivations that led to subsequent changes. We observed patterns of convergence, then posited probe questions (Dick 2005) to drill down and confirm our observations. Unlike our previous interviews (Kennard, Edmonds & Leaney 2009) we were not looking to generalise or codify. Rather every comment, even in isolation, was valuable to help understand the team's research.

The authors and the Naked Objects team had worked independently up to this point, but learnt much about each other's work during the course of the exchange. Most notably, we discovered a surprising amount of convergence around the key characteristics we had previously identified (Kennard & Leaney 2010). In the next section, we record our findings, framed in the context of the five characteristics defined in section 1.

4. Interview

Dan started the discussion with an overview of the current design. Recap that Pawson (2004) had summarized: "Using the naked objects approach to designing a business system, the domain objects are exposed explicitly, and automatically, to the user, such that all user actions consist of viewing objects, and invoking behaviours that are encapsulated in those objects". This results in an Object Oriented User Interface (OOUI) as shown below:

The UI is a direct representation of the domain objects, with UI actions explicitly creating and retrieving domain objects and invoking an object's methods. The advantage of this approach is that the UI can be built and reworked very rapidly from the domain.

Dan then elaborated on the architecture. "First off, in terms of what Naked Objects/Apache Isis actually is, these days I think of it in terms of the hexagonal architecture:"

"The hexagon core has got two main bits to it - the metamodel (cf. a class) and the runtime (cf. an object). Plugging into the hexagon are the back-end object stores [labelled 'persistence'], and the front-end viewers [labelled 'main' and 'webapp']".

"The metamodel [the hexagon] defines the ObjectSpecification which describes the class, its inheritance hierarchy, its class members. The runtime defines the ObjectAdapter, which wraps each [domain object]. This references the ObjectSpecification and also references an opaque Object Identifier (OID), basically an abstraction over primary keys (since it is assigned by the object store) though non-persisted objects also have an OID. The runtime also manages the identity of the (entity) object, each of which is identified in a multiway identity map of [domain object] <-> ObjectAdapter <-> OID. The back-end object store implementations deal mostly with the runtime; some use the metamodel (e.g. XML object store), some don't (e.g. JPA object store, because [JPA] builds its own metamodel). The front-end viewer implementations deal mostly with the metamodel in that they use it to render the [domain objects]".

The interview then moved to discuss back-end object stores, the metamodel and front-end viewers in detail. The authors discovered a significant amount of convergence with our own key characteristics, identified previously (Kennard & Leaney 2010).

4.1 Inspecting existing, heterogeneous back-end architectures

The authors had previously identified (Kennard & Leaney 2010) that supporting a mixture of heterogeneous sources of UI metadata was an important characteristic for a practical UI generator. Many business systems are modelled as 'anaemic' (Fowler 2002) or 'dumb' (Firesmith 1996) entities surrounded by controller objects such as persistence contexts, validation subsystems and rule engines. This has implications for frameworks implementing the naked objects pattern, with its original tenet of 'behavioural-completeness' dictating that "all the functionality associated with a given entity [must be] encapsulated in that entity, rather than being provided in the form of external functional procedures that act upon the entities" (Pawson 2004). Our adoption studies showed practitioners resisted "many frameworks or tools [that] enforce the [framework] designer's vision on how solutions should be architected" (Kennard & Leaney 2010).

Interestingly, however, the latest release of the naked objects frameworks include a concept called 'facets'. The authors wanted to clarify if these were in the original design? Dan Haywood responded: "No, they weren't". What was their background? "Up until 3.0 (late 2007) I had actually been working on my own [clean room implementation of a naked objects framework] based on Eclipse RCP. For various reasons, I wrote it off. But all was not lost: a lot of my thoughts on what the programming model should look like went into Naked Objects 4.0 (2009). I also had become enamoured with the extension object pattern, something used a lot in the Eclipse APIs. It was this that eventually evolved into facets".

Dan explained that facets were a form of an extension object pattern, allowing capture of metadata from heterogeneous sources. How did this fit in to a naked objects architecture? Dan explained "Rob [Matthews] and I started refactoring the Naked Objects metamodel to bring in this idea [of the extension object pattern]. My original idea didn't go much beyond representing the [existing Naked Objects] annotations as facets... like all good collaborations, one of us (and I'm pretty sure it was Rob) realised that the imperative helper methods could also be captured as facets too". Is it one facet per technology? "No. It's one facet per piece of information to be captured. A collection of facets define the Naked Objects ProgrammingModel. Suppose there's a Java Persistence API (JPA) annotation (or bit of XML, it could be) to indicate that a field is nullable... that would correspond to a JpaMandatoryFacet. And if we wanted to capture which property was the Id (which I do, to manufacture the framework's internal identifier) then there's also a JpaIdFacet. This is what I meant about a programming model: the JpaProgrammingModel is the collection of the FacetFactories for detecting these features/semantics/pieces of information and adding them to the code". Can a facet be targeted outside of the entity (i.e. XML files, database schemas, rule engines)? "Yes... a FacetFactory can pick up information from anywhere. We have a little example showing how names could be picked up from a flat file".

In short, are facets close to Metawidget's Inspectors and its CompositeInspector? "Pretty similar, but more fine-grained. I think CompositeInspector = a Naked Objects ProgrammingModel = collection of Facets. But it'd be good if we went closer to [Metawidget's] design, with an Inspector = a group of related facets that shouldn't be split apart. Our facets are too fine-grained and I think we should instead be dealing in an aggregation of facets, which I'm calling a ProgrammingModel, basically equivalent to your Inspector. Then, another idea I intend to borrow is that of CompositeInspector which for us would be a CompositeProgrammingModel".

The authors discovered that with their introduction of facets, particularly XML and flat file facets, the Naked Objects team had effectively extended their philosophy of behavioural-completeness (Pawson 2004) to go beyond just the semantics intrinsic within the code. They had converged on a need to support a mixture of heterogeneous sources of UI metadata. Their implementation differed a little from the authors' in that it was "more fine-grained". But the fundamental notion of opening up the naked objects frameworks to metadata from other subsystems, such as persistence contexts, rule engines and XML files, had close parity with our approach.

4.2 Appreciating different practices in applying inspection results

A second key characteristic the authors identified (Kennard & Leaney 2010) was to support a variety of ways to post process the UI metadata. For example, different practitioners had different preferences regarding how to sort or exclude business properties from the UI.

The authors discovered the Naked Objects team had also perceived this need. Dan described: "our FacetFactorys can optionally implement various additional interfaces. To identify the properties and collections (i.e. identify the main scaffolding of the classes) we look for FacetFactorys (typically just one) that implements the PropertyOrCollectionIdentifyingFacetFactory interface. These are run through first. I think it might be better to pull this out as a distinct phase of the metamodel building process. Similarly, after we've processed all the FacetFactories and added the facets then we go looking for MemberOrderFacets to sort the members; it's just a call to a method. Again, it might make sense to factor this out into a separate API".

The Naked Objects team were clearly thinking about introducing post processing into their facets. They were already using multiple passes implicitly - "these are run through first... similarly, after we've processed all the [others]" - and were now seeing that separating this out into an explicit post processing phase may be advantageous. Metawidget had followed a similar evolution. The authors had originally had the Inspectors performing the sorting themselves, but factored this out into a separate InspectionResultProcessor API.

4.3 Recognising multiple, and mixtures of, UI widget libraries

Another key characteristic the authors identified (Kennard & Leaney 2010) was supporting mixtures of widget libraries. This included mixing multiple third-party widget libraries, and the practitioner's own custom widget libraries, in addition to the UI platform's standard widget libraries.

The authors wanted to gain an understanding of how this characteristic had been handled in the original naked objects pattern. Dan recounted: "the different viewers implement this differently. The original viewer had something similar, but restricted to just using AWT. That's fine, but it does mean that a developer wanting to extend the viewer has to learn all this new API".

Had newer viewers tried to incorporate better support for third-party, or custom, widget libraries? "Talking about the Apache Wicket viewer, the API is actually called ComponentFactory. Part of the reason for using that terminology is to use a term that's already known by Wicket developers who might want to extend the UI generated by the Wicket viewer. I have a registry of ComponentFactories, which are asked in a chain-of-responsibility pattern to render model objects. They may use third party libraries if necessary". Can you compose multiple ComponentFactories in one project? "Yes. Basically the Wicket viewer is just a registered collection of ComponentFactories that can render any entity or collection of entities. But the list is pluggable so that custom widgets can be provided if required". Can you specify precedence? "Yes, it's a first-come-first-served. So, any ComponentFactories picked up on the classpath are placed before the defaults. But our programmatic approach provides full control".

In short, are they close to Metawidget's WidgetBuilders and its CompositeWidgetBuilder? "So, yes, kind of similar. But, as I say, [ComponentFactories are] an implementation detail of each viewer - the nature of the API is not standardised across viewers. In theory that sounds like a good objective, and I think it's something you've managed to achieve with Metawidget. I'm hoping that within Apache Isis we'll be able to move some of this stuff into core, so that it can be reused more widely. It might also make sense to move the ComponentFactoryRegistry stuff there too, though I'd need to figure out how to remove any Wicket-specific stuff".

The Naked Objects team had progressed from originally using a proprietary, low-level APIs to fully supporting pluggable third-party libraries via ComponentFactories. In the future they hoped to back port this approach from its current per-viewer implementation into the Naked Objects core proper. There was clear convergence in this characteristic.

4.4 Supporting multiple, and mixtures of, UI adornments

The authors further identified (Kennard & Leaney 2010) that supporting a variety of ways to post process UI widgets was an important characteristic for a practical UI generator. Once created, widgets may need to be adorned with such mechanisms as data validators, data binding frameworks and event handlers. Some of these mechanisms, such as validators, may come from a different third-party library to the widget itself.

The latest release of Naked Objects included a concept called 'advisors'. Were these in the original design? "No; we introduced them in Naked Objects 4.0 (2009)". Dan explained advisors handled such operations as hiding, disabling, and validating components. "To clarify: some facets are also advisors, some facets aren't. There are no advisors that aren't also facets. Consider the [Naked Objects] @Disabled annotation. That is going to get picked up by the DisabledViaAnnotationFacetFactory, which installs a DisabledFacet on the property. When the viewer creates the text box [for the property] it doesn't go looking directly for a DisabledFacet. What it does instead is call property.isDisabled which iterates through all installed facets looking for those that implement DisableInteractionAdvisor (of which the DisabledFacet will be one). If one of those advisors or facets vetoes, then it configures the text box accordingly".

This results in the sequence diagram depicted below:

The sequence has similarities with Metawidget's own pipeline (Kennard & Leaney 2010) depicted below:

In particular, the similarities between facets and inspectors, component factories and widget builders, and advisors and widget processors. Considering neither facets, component factories nor advisors were part of the original naked objects pattern (Pawson 2004) this showed strong evidence of convergence.

However, Dan's description was of a single object implementing both the Facet interface and the Advisor interface. These interfaces are roughly analogous to Metawidget's Inspector and WidgetProcessor interfaces, but Metawidget implements these as separate objects. This is because the former is tied to the back-end architecture whereas the latter is tied to the front-end UI. Is this something the Naked Objects team have considered? "[Yes] all the above said... I'm not entirely sure that there's any real need for a facet to be an advisor. Where at the moment a ObjectMember implements FacetHolder, it could perhaps be also an AdvisorHolder. This would separate out these concerns, converging our two designs further".

4.5 Applying multiple, and mixtures of, UI layouts

A final characteristic the authors identified (Kennard & Leaney 2010) was supporting multiple ways to arrange widgets on the screen. We pointed out that it significantly detracts from the practicality of automated generation if it in any way compromises the final product in usability, or even in aesthetics (Myers, Hudson & Pausch 2000, p. 13). This realisation exposes a myriad of small details around UI appearance, navigation, menu placement and so on. The problem is so difficult, in fact, we believe it insoluble.

Metawidget sidesteps the issue by not attempting to generate the entire UI. Rather, it believes there are 'useful bounds' to UI generation: "as automatic UI generation moves away from [simply modelling fields as forms] it rapidly becomes highly speculative. Determining how to display a domain object is much more subjective than determining what fields to display. Determining how to represent relationships between multiple domain objects is more subjective still. The practical usefulness of UI generation diminishes once in these areas, because the generated UI bears less and less resemblance to how it would have appeared and functioned had it been designed manually, with consideration to its specific purpose" (Kennard & Steele 2008). As Constantine (2002) puts it "the greatest usability problem with Naked Objects is the one-size-fits-all premise on which the approach rests. Instead of tailoring the presentation of information and the operation of the UI to fit the unique aspects of the context, the application, and the user needs, one [generic presentation layer] is presumed to fit all problems". Instead, Metawidget focuses on generating only a small piece of the UI - the 'inside' of each page, the area around the fields themselves. The UI appearance, navigation, menu placement and overall usability are far more subjective and we explicitly keep these out of scope.

Even after Metawidget has restricted its UI generation to just the area around fields, we find there is still a formidable degree of variability. Fields may typically be arranged in a 'column', with the widget on the right and its label on the left. But there are many other real world arrangements, such as all fields arranged in a single, horizontal row; or right-to-left arrangements for the Arabic world. It is important to accommodate this variability if the generator is to achieve the exact look the practitioner desires. Metawidget addresses this characteristic of supporting multiple ways to arrange widgets by defining pluggable layouts.

In contrast, the original Naked Objects viewers did not admit this level of subjectivity. Dan explains: "there's lots of scepticism that a fully generic UI is sufficient [but] I don't think we recognise that... at least not for the enterprise applications that we have built thus far. In the Irish [Department of Social Protection] system there are about 5 or 6 transient entities [intermediate, subjective representations of domain objects] out of over 300 sovereign entities [direct representations of domain objects]. So, the point is... most entities don't need them". Dan summarised "[Metawidget] just provides, well, a widget (a rather large and clever one, but a widget nonetheless)". Naked Objects, on the other hand provides the full UI - "the scope of Naked Objects is larger than Metawidget".

But Dan also noted that the naked objects frameworks provide a blunt level of pluggability so that entire viewers can be plugged in to provide different UIs: "the technology used by any given viewer is generally fixed (AWT, Wicket, JSF etc). But some viewers do provide pluggable layouts in a manner similar to that allowed by Metawidget. Rob's Scimpi web viewer [a Naked Objects viewer that produces similar results to figure 1 but using a web-based platform], for example, provides a whole slew of tags that can be assembled onto a page to provide a rendering of an object, collection or action dialog [Scimpi 2010]. The only real assumption that Scimpi makes is what is being rendered is going to be one of these things (an object, collection or action dialog). Even then, Scimpi's tags allow other information to be 'mixed-into' the page (e.g. the name of the currently logged-on user)". Dan then went on to describe his Wicket viewer: "the Wicket viewer likewise looks for a page to render an object, collection or whatever. Where it differs from Scimpi is really just that its rendering is done not using tags but using Wicket components".

The Scimpi and Wicket viewers therefore provide evidence of convergence. There is still a gap between approaches in that Metawidget places no expectations on the 'outside' of each page, whereas the naked objects viewers expect the entire page to map to an instance of something within their metamodel. Also, plugging in new viewer implementations is not something the Naked Objects team expects practitioners to undertake. Dan agreed: "it's a lot of work. Maybe in time we'll mature this somewhat and make it easier by pulling some common building blocks into the core (i.e. closer to how Metawidget works, I imagine), but for now that isn't the case".

5. Convergence in Other Projects

This article has explored convergence between our own work and that of the Naked Objects team. Given the intricacies and subtleties of the design decisions involved, it was necessary to cover their project in depth and in detail. Therefore this study focussed on only a single project.

Clearly there are other UI generator projects that also demonstrate a significant industry presence. For example, UsiXML (Vanderdonckt et al. 2004) is a cross device, platform and modality UIDL that has been submitted to the W3C industry body for standardization. OlivaNOVA (Valverde et al. 2007) is a commercially available product that can generate UIs for both Java and Microsoft .NET environments. Such projects have differentiating characteristics beyond, though not necessarily mutually exclusive to, our own five. We have asserted that our five characteristics are fundamental for a UI generator to be useful to industry. The characteristics have been derived over successive iterations of Action Research cycles with industry practitioners, and validated by industry adoption studies and open-ended interviews (Kennard & Leaney 2010). Demonstrably, they are important enough that the Naked Objects team found the need to add them atop their original design.

However ours are not the only characteristics by which UI generators may be assessed, nor the only ones by which they may converge. Examples of other generators and their differentiating characteristics are shown in the table below. This table shows a selection of features drawn both from our own five and from the feature sets of the generators as described in the literature. It can be seen there are differing approaches to implementing any given characteristic, and some can be left to the practitioner to implement manually without the UI generator's explicit support. This may or may not be enough for the generator to prove sufficiently useful to industry.

Feature/Generator	Metawidget	Naked Objects	UsiXML	OlivaNOVA
Inspecting existing, heterogeneous back-end architectures	Yes	Yes (see 4.1)	No, has its own UIDL	No, has its own UIDL
Appreciating different practices in applying inspection results	Yes	Yes (see 4.2)	No, but can edit generated code	No, but can edit generated code
Recognising multiple, and mixtures of, UI widget libraries	Yes	Yes (see 4.3)	No, but can edit generated code	No, but can edit generated code
Supporting multiple, and mixtures of, UI adornments	Yes	Yes (see 4.4)	No, but can edit generated code	No, but can edit generated code
Applying multiple, and mixtures of, UI layouts	Yes	Partial (see 4.5)	No, but can edit generated code	No, but can edit generated code
Mode of operation	Runtime	Runtime	Static code generation	Static code generation
Translation to different devices, platforms, modalities	Manual (see 4.5)	Automatic	Automatic	Automatic
Object Oriented User Interface	No	Yes (see 4)	No	Yes

Research projects such as UsiXML and OlivaNOVA will require further exploration to look for signs of convergence. If our characteristics are as fundamental as we believe, these research teams should be identifying similar constructs through their own industry field trials. Conversely, if we find these teams to be converging on a different set of characteristics, that would also be very instructive.

6. Conclusions and Future Work

Through interviewing the Naked Objects team, the authors discovered there was broad agreement on four out of five of our key characteristics. None of these were considered an explicit feature of the original naked objects pattern and all had evolved independently within our two projects, so this represented good evidence of convergence. Our interview also established there were areas where our project philosophies differed, and were likely to remain in disagreement.

In our previous article (Kennard & Leaney 2010) the authors reasoned that implementation of all five of our characteristics would lead to a notable emergent advantage: being able to retrofit an existing application that was not built with UI generation in mind. For example, one could retrofit a word processor: the main word processing area would be left untouched, but the numerous dialog boxes for application and formatting preferences could be retrofitted to use UI generation. Metawidget demonstrates this advantage but the naked objects frameworks do not, because there is still a gap around pluggable layouts which limits the categories of applications the naked objects pattern can be applied to. Dan agreed: "realistically, we aren't ever going to see a word processor written in naked objects.... but I'm interested in figuring out how many UI screens can be thought of as a rendering of an object, a collection or action dialog. The customisable UI then amounts to allowing the developer to specify which properties/collections/actions of that single object to appear where, and which to be omitted... the short answer is yes, we want naked objects to be more applicable. It's about removing objections from folks trying out the framework". Clearly there is room for future research and healthy competition between the two projects.

In conclusion the authors consider it significant that a good many core, non-obvious characteristics have been established. These have been agreed upon both by our own industry adoption studies, and independently by the industry field trials of the Naked Objects team. We believe these signal the beginning of a general purpose architecture for UI generation, one that both industry and the research community could standardise upon. This standardisation could then be used to drive adoption and ultimately to realise the full potential of UI generation technology.

References

Bodart, F., Hennebert, A.M., Leheureux, J.M., Provot, I., Sacre, B. & Vanderdonckt, J. 1995, 'Towards a Systematic Building of Software Architectures: the TRIDENT Methodological Guide', Design, SpecCeification and Verification of Interactive Systems. Wien: Springer, pp. 262-278.
Calvary, G., Coutaz, J., Thevenin, D., Limbourg, Q., Bouillon, L. & Vanderdonckt, J. 2003, 'A unifying reference framework for multi-target user interfaces', Interacting with Computers, vol. 15, no. 3, pp. 289-308.
Constantine, L. 2002, 'The emperor has no clothes: Naked Objects meet the interface', Constantine Lockwood, http://www.foruse.com/articles.
Daniel, F., Matera, M., Yu, J., Benatallah, B., Saint-Paul, R. & Casati, F. 2007, 'Understanding UI Integration: A Survey of Problems, Technologies, and Opportunities', IEEE INTERNET COMPUTING, pp. 59-66.
Dick, B. 2005, 'Grounded theory: a thumbnail sketch', http://www.scu.edu.au/schools/gcm/ar/arp/grounded.html
Falb, J., Popp, R., Rock, T., Jelinek, H., Arnautovic, E. & Kaindl, H. 2007, 'Fully-automatic generation of user interfaces for multiple devices from a high-level model based on communicative acts', System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on, ed. P. Roman, p. 26.
Firesmith, D.G. 1996, Use Cases: The Pros and Cons. Wisdom of the Gurus: A Vision for Object Technology.
Fowler, M. 2002, Patterns of Enterprise Application Architecture. Addison Wesley.
Hayes, P.J., Szekely, P.A. & Lerner, R.A. 1985, 'Design alternatives for user interface management sytems based on experience with COUSIN', Proceedings of the SIGCHI conference on Human factors in computing systems, pp. 169-175.
Haywood, D. 2009, 'Domain Driven Design using Naked Objects', Pragmatic Bookshelf.
Jelinek, J. & Slavik, P. 2004, 'GUI generation from annotated source code', Proceedings of the 3rd annual conference on Task models and diagrams, pp. 129-136.
Jha, N.K. 2005, 'Low-power system scheduling, synthesis and displays', Computers and Digital Techniques, IEE Proceedings, vol. 152, no. 3, pp. 344-352.
Kennard, R. & Steele, R. 2008, Application of Software Mining to Automatic User Interface Generation. 7th International Conference on Software Methodologies, Tools and Techniques.
Kennard, R., Edmonds, E. & Leaney, J. 2009, Separation Anxiety: stresses of developing a modern day Separable User Interface. 2nd International Conference on Human System Interaction.
Kennard, R. & Leaney, J. 2010, Towards a General Purpose Architecture for UI Generation. Journal of Systems and Software.
Myers, B.A. & Rosson, M.B. 1992, Survey on user interface programming, ACM Press New York, NY, USA.
Myers, B., Hudson, S.E. & Pausch, R. 2000, 'Past, present, and future of user interface software tools', ACM Transactions on Computer-Human Interaction (TOCHI), vol. 7, no. 1, pp. 3-28.
Pawson, R. 2004, 'Naked Objects' thesis, Trinity College, Dublin.
Pawson, R. & Matthews, R. 2002 'Naked Objects', Wiley.
Rouvellou, I., Degenaro, L., Rasmus, K., Ehnebuske, D. & Mc Kee, B. 1999, 'Externalizing Business Rules from Enterprise Applications: An Experience Report', Practitioner Reports in the OOPSLA, vol. 99.
Shan, T.C., Hua, W.W., Bank, W. & Wilmington, N.C., 2006. 'Taxonomy of java web application frameworks', pp. 378-385.
Valenzuela, D. & Shrivastava, P. 2002, 'Interview as a Method for Qualitative Research', http://www.public.asu.edu/~kroel/www500/Interview%20Fri.pdf.
Valverde, F., Valderas, P., Fons, J. & Pastor, O. 2007, 'A MDA-Based Environment for Web Applications Development: From Conceptual Models to Code', Citeseer.
Vanderdonckt, J., Limbourg, Q., Michotte, B., Bouillon, L., Trevisan, D. & Florins, M. 2004, 'USIXML: a User Interface Description Language for Specifying Multimodal User Interfaces', W3C Workshop on Multimodal Interaction. Sophia Antipolis, pp. 19-20.
Weiser, M. 1993, 'Hot topics-ubiquitous computing', Computer, vol. 26, no. 10, pp. 71-72.
Xudong, L. & Jiancheng, W. 2007, 'User Interface Design Model', Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, 2007. SNPD 2007. Eighth ACIS International Conference on, vol. 3.

User Interface Generator: Metawidget v1.20

2011-05-12T15:52:00.001+10:00

Version 1.20 of Metawidget, the User Interface Generator is now available! This is a minor release, mainly to fix bugs in the examples. I discovered the 'initial experience' on the latest version of Apache Tomcat (version 7) was pretty bad and may give a negative first impression to new users. The release includes the following enhancements:

Improved examples to work better with Tomcat 7
Improved module POMs to work better with m2eclipse
Allow JavaBeanPropertyStyle to disable caching
Allow location of metawidget.xml to be configured in web.xml
Bug fixes, documentation and unit tests

Metawidget at Red Hat Summit 2011

2011-05-11T16:09:00.001+10:00

Metawidget got a good showing at Red Hat Summit 2011 this year, following on from our campground session in 2010.

Metawidget was included in 3 sessions:

Seam Forge: Forge New Ground in Rapid Enterprise Java Development (Video)
Bean Validation: Best practices for real life (PDF)
Seam Catch: Handling the Unexpected (PDF, Source Code)

My thanks to all the presenters for their support!

Object User Interface Mapper (OIM): Metawidget v1.15

2011-04-30T20:37:00.004+10:00

Version 1.15 of Metawidget, the Object User Interface Mapping tool (OIM) is now available! This release includes the following enhancements:

Maven support
Streamlined Configuration
RichFaces 4 support
Bug fixes, documentation and unit tests

As always, the best place to start is the Reference Documentation:

http://metawidget.org/doc/reference/en/pdf/metawidget.pdf

Special thanks to Renato Garcia and Lincoln Baxter III for their help with this release!

Your continued feedback is invaluable to us. Please download it and let us know what you think.

Metawidget: RichFaces 4 support

2011-04-28T17:10:00.009+10:00

The next release of Metawidget (v1.15) will include support for RichFaces 4 (previously we only supported 3.3.3.Final). Code and unit tests are already available in SVN, and here are some screenshots:

This support requires MyFaces 2.0.5 or above, or a version of Mojarra that includes this fix.

Metawidget: Streamlined Configuration

2011-04-20T11:39:00.004+10:00

The next release of Metawidget (v1.15) will include a small enhancement to the metawidget.xml syntax used by ConfigReader. ConfigReader has always been designed to automatically recognise and reuse immutable instances. This works both when configuring multiple Metawidgets, and configuring multiple settings for a single Metawidget. So if you did...

<inspectors> <array> <java5Inspector xmlns="java:org.metawidget.inspector.java5" config="org.metawidget.inspector.impl.BaseObjectInspectorConfig"> <propertyStyle> <javaBeanPropertyStyle xmlns="java:org.metawidget.inspector.impl.propertystyle.javabean" config="JavaBeanPropertyStyleConfig"> <supportPublicFields> <boolean>false</boolean> </supportPublicFields> <privateFieldConvention> <format>'m'{1}</format> </privateFieldConvention> </javaBeanPropertyStyle> </propertyStyle> </java5Inspector> <metawidgetAnnotationInspector xmlns="java:org.metawidget.inspector.annotation" config="org.metawidget.inspector.impl.BaseObjectInspectorConfig"> <propertyStyle> <javaBeanPropertyStyle xmlns="java:org.metawidget.inspector.impl.propertystyle.javabean" config="JavaBeanPropertyStyleConfig"> <supportPublicFields> <boolean>false</boolean> </supportPublicFields> <privateFieldConvention> <format>'m'{1}</format> </privateFieldConvention> </javaBeanPropertyStyle> </propertyStyle> </metawidgetAnnotationInspector> </array> </inspectors>

...ConfigReader would be smart enough to reuse the same javaBeanPropertyStyle instance. But you still had to specify all javaBeanPropertyStyle's configuration options twice. In v1.15 you can instead use id and refId to refer from one setting to another:

<inspectors> <array> <java5Inspector xmlns="java:org.metawidget.inspector.java5" config="org.metawidget.inspector.impl.BaseObjectInspectorConfig"> <propertyStyle> <javaBeanPropertyStyle xmlns="java:org.metawidget.inspector.impl.propertystyle.javabean" config="JavaBeanPropertyStyleConfig" id="myPropertyStyle"> <supportPublicFields> <boolean>false</boolean> </supportPublicFields> <privateFieldConvention> <format>'m'{1}</format> </privateFieldConvention> </javaBeanPropertyStyle> </propertyStyle> </java5Inspector> <metawidgetAnnotationInspector xmlns="java:org.metawidget.inspector.annotation" config="org.metawidget.inspector.impl.BaseObjectInspectorConfig"> <propertyStyle> <javaBeanPropertyStyle refId="myPropertyStyle" /> </propertyStyle> </metawidgetAnnotationInspector> </array> </inspectors>

It's a small thing, but can shorten your metawidget.xml in a big way.

Feedback welcome!

Metawidget: Maven Snapshot Releases

2011-04-11T17:13:00.009+10:00

I'm thrilled to say that the first snapshot releases of Metawidget 1.15 are now available in the JBoss Snapshot Repository at https://repository.jboss.org/nexus/content/repositories/snapshots/org/metawidget:

<repository> <id>jboss-snapshots</id> <url>https://repository.jboss.org/nexus/content/repositories/snapshots</url> </repository> ... <dependency> <groupId>org.metawidget.modules</groupId> <artifactId>metawidget-all</artifactId> <version>1.15-SNAPSHOT</version> </dependency>

I plan to be staging the modules here for a few weeks before the final 1.15 release. I'd be most grateful to anybody who could download them and take the new fine-grained module system for a spin.

My thanks to Renato Garcia for his help with the Maven migration.

Feedback most welcome!

Grokking Seam Forge: Part 3

2011-04-01T19:59:00.008+11:00

JBoss have just released Seam 3.0.0.Final, which includes Alpha 3 of Seam Forge. So I thought I'd improve my previous blog entry:

First, download Seam from here
Unzip to a folder of your choosing
Run bin\forge

Type the following commands and press ENTER after each one. Accept any defaults you are prompted for, and remember to use TAB and UP ARROW autocomplete:

new-project --named MyApp --topLevelPackage com.myapp persistence setup --provider HIBERNATE --container JBOSS_AS6 new-entity --named Person new-field string --named firstname new-field string --named surname new-field int --named age new-field string --named notes new-field custom --named homeAddress [type=The qualified Class to be used as this field's type (of type java.lang.String)]: com.myapp.Address new-field custom --named workAddress [type=The qualified Class to be used as this field's type (of type java.lang.String)]: com.myapp.Address new-entity --named Address new-field string --named street new-field string --named suburb new-field string --named state new-field string --named postcode scaffold from-entity com.myapp.domain.Person.java exit

Open Eclipse (with m2eclipse installed)

Choose File > Import > Existing Maven Projects and import the pom.xml at \seam-3.0.0.Final\forge\MyApp\pom.xml

Right click the pom.xml and choose Run As > Maven package

Take the WAR it generates under target/MyApp-1.0.0-SNAPSHOT.war and deploy it under JBoss AS 6.0.0.Final

Open your browser at http://localhost:8080/MyApp-1.0.0-SNAPSHOT/scaffold/person/list.jsf:
Now, let's play around a bit! These are things that soon Forge will be able to do for you, but for now edit Person.java and add the lines in bold:

package com.myapp.domain; import javax.persistence.Column; import javax.persistence.Entity; import javax.persistence.GeneratedValue; import javax.persistence.GenerationType; import javax.persistence.Id; import javax.persistence.Lob; import javax.persistence.Version; import org.metawidget.inspector.annotation.UiComesAfter; import org.metawidget.inspector.annotation.UiSection; @Entity public class Person implements java.io.Serializable { @Id private @GeneratedValue( strategy = GenerationType.AUTO ) @Column( name = "id", updatable = false, nullable = false ) long id = 0; @Version private @Column( name = "version" ) int version = 0; public long getId() { return this.id; } public void setId( final long id ) { this.id = id; } public int getVersion() { return this.version; } public void setVersion( final int version ) { this.version = version; } @Column private String firstname; public String getFirstname() { return this.firstname; } public void setFirstname( final String firstname ) { this.firstname = firstname; } @Column private String surname; @UiComesAfter( "firstname" ) public String getSurname() { return this.surname; } public void setSurname( final String surname ) { this.surname = surname; } @Column private int age; @UiComesAfter( "surname" ) public int getAge() { return this.age; } public void setAge( final int age ) { this.age = age; } @Column private String notes; @UiComesAfter( "workAddress" ) @Lob @UiSection( "Other" ) public String getNotes() { return this.notes; } public void setNotes( final String notes ) { this.notes = notes; } @Column private Address homeAddress = new Address(); @UiComesAfter( "age" ) @UiSection( "Details" ) public Address getHomeAddress() { return this.homeAddress; } public void setHomeAddress( final Address homeAddress ) { this.homeAddress = homeAddress; } @Column private Address workAddress = new Address(); @UiComesAfter( "homeAddress" ) public Address getWorkAddress() { return this.workAddress; } public void setWorkAddress( final Address workAddress ) { this.workAddress = workAddress; } @Override public String toString() { return this.getClass().getSimpleName() + "[" + id + ", " + version + ", " + firstname + ", " + surname + ", " + age + ", " + notes + ", " + homeAddress + ", " + workAddress + "]"; } }

Similarly for Address.java:

Then tell metawidget.xml we'd like to use RichFaces:

And tell web.xml the same (update: this can be done using the richfaces-forge-plugin, see the comments below):

<web-app > ... <filter> <display-name>RichFaces Filter</display-name> <filter-name>richfaces</filter-name> <filter-class>org.ajax4jsf.Filter</filter-class> </filter> <filter-mapping> <filter-name>richfaces</filter-name> <servlet-name>Faces Servlet</servlet-name> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>INCLUDE</dispatcher> </filter-mapping> <servlet> <servlet-name>Faces Servlet</servlet-name> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>Faces Servlet</servlet-name> <url-pattern>*.jsf</url-pattern> </servlet-mapping> </web-app>

And finally pom.xml too (update: this can be done using add-dependency, see the comments below):

<dependencies> ... <dependency> <groupId>org.richfaces.ui</groupId> <artifactId>richfaces-ui</artifactId> <version>3.3.3.Final</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.richfaces.framework</groupId> <artifactId>richfaces-impl</artifactId> <version>3.3.3.Final</version> <scope>compile</scope> </dependency> </dependencies>

Then redeploy your app and hit http://localhost:8080/MyApp-1.0.0-SNAPSHOT/scaffold/person/list.jsf again:
Of course, Seam Forge is still in alpha so not everything works yet. But hopefully this has whetted your appetite for things to come!

Metawidget: Full Speed To Maven

2011-03-25T16:41:00.007+11:00

The next release of Metawidget (v1.15) represents a significant rearrangement of our source tree, as we migrate the codebase from Ant to Maven.

I'm not going to knock Ant: it's been a great build tool for us, and it's much more flexible than Maven in many regards. But there are some compelling reasons for us to switch:

Metawidget wires up existing technologies, and there are lots of them.
I really like the idea of a single metawidget.jar that's easy to deploy and get running, but there are some use cases where this isn't sufficient. For example, perhaps you want to save space by deploying only those Metawidget plugins you actually use. Or perhaps you need to deploy different plugins on different application tiers.

We need a path from the easy-to-use but monolithic metawidget.jar to this 'fine-grained' use case. Maven gives us this path. So with v1.15 you'll be able to do either...

<dependency> <groupId>org.metawidget.modules</groupId> <artifactId>metawidget-all</artifactId> </dependency>

Or you can specify fine-grained dependencies...

<dependency> <groupId>org.metawidget.modules.faces</groupId> <artifactId>metawidget-richfaces</artifactId> </dependency> <dependency> <groupId>org.metawidget.modules</groupId> <artifactId>metawidget-jpa</artifactId> </dependency> <dependency> <groupId>org.metawidget.modules</groupId> <artifactId>...other modules...</artifactId> </dependency>

Maven will automatically drag in related dependencies for you, such as org.metawidget.modules:metawidget-core.
Metawidget needs lots of high quality examples.
Whether it's examples on how to run Metawidget on Android, or in GWT Hosted Mode, or with JSF 2, or how to write custom Inspectors or WidgetBuilders - high quality examples are critical. Maven lets us compose each small piece of Metawidget (every example, every plugin) as a standalone project. This makes it easy to use tools such as m2eclipse to open the individual pom.xml in your IDE and start experimenting!

Some great tools play nicer with Maven.
Tools such as Jenkins and Sonar, which should have a direct bearing on maintaining our code quality.

Don't Panic!

To ally any concerns, allow me to stress:

Metawidget v1.15 will be backwards compatible with v1.10.
In fact, the binaries will be almost identical. Only the build system has been rewritten.
Metawidget will not require Maven to use.
We will still be packaging metawidget-1.15.zip and metawidget-1.15-src.zip distributions that you can download, just as before.

All up, I don't think anything will be lost (apart from sweat and tears rearranging the code) and hopefully a lot will be gained. I've branched the old v1.10 codebase in SVN and checked in an early copy of the Maven version. I'd say it's about 75% done (and has nearly 100 POMs!)

I'd be most grateful to anybody who could check it out and provide feedback.

Grokking Seam Forge: Part 2

2011-03-09T16:23:00.009+11:00

JBoss have just released Seam 3.0.0.CR2, which includes Alpha 2 of Seam Forge. It's an alpha, so expect pain, but let's take it for a spin!

First, download Seam Forge from here
Unzip to a folder of your choosing
Run bin\forge

Seam Forge is command-line driven, similar to Rails and Roo (though with loftier goals :). Type the sections in bold:

[no project] forge-1.0.0.Alpha2 $ new-project --named MyApp --topLevelPackage com.myapp Use [/forge-1.0.0.Alpha2/MyApp] as project directory? [Y/n] y Wrote /forge-1.0.0.Alpha2/MyApp/src/main/resources/META-INF/forge.xml ***SUCCESS*** Created project [MyApp] in new working directory [/forge-1.0.0.Alpha2/MyApp] [MyApp] MyApp $ persistence setup --provider HIBERNATE --container JBOSS_6 Wrote /forge-1.0.0.Alpha2/MyApp/src/main/resources/META-INF/persistence.xml ***SUCCESS*** Installed [forge.spec.jpa] successfully. Wrote /forge-1.0.0.Alpha2/MyApp/src/main/resources/META-INF/persistence.xml [MyApp] MyApp $ new-entity --named Person In which package you'd like to create this @Entity, or enter for default: [com.myapp.domain] Wrote /forge-1.0.0.Alpha2/MyApp/src/main/java/com/myapp/domain/Person.java Created @Entity [com.myapp.domain.Person] Picked up type : com.myapp.domain.Person [MyApp] Person.java $ new-field string --fieldName firstName Wrote /forge-1.0.0.Alpha2/MyApp/src/main/java/com/myapp/domain/Person.java Added field to com.myapp.domain.Person: @Column private String firstName; [MyApp] Person.java $ new-field string --fieldName surname Wrote /forge-1.0.0.Alpha2/MyApp/src/main/java/com/myapp/domain/Person.java Added field to com.myapp.domain.Person: @Column private String surname; [MyApp] Person.java $ cd .. [MyApp] domain $ scaffold from-entity com.myapp.domain.Person.java The [forge.maven.WebResourceFacet] facet requires the following packaging type [war], but is currently [jar], would you like to change the packaging to [war]? (Note: this could break other plugins in your project.) [Y/n] y Packaging updated to [war] ***SUCCESS*** Installed [forge.maven.WebResourceFacet] successfully. Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/WEB-INF/beans.xml ***SUCCESS*** Installed [forge.spec.cdi] successfully. The [forge.spec.jsf] facet depends on the following missing facets: [forge.spec.servlet]. Would you like to attempt installation of these facets as well? [Y/n] y Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/WEB-INF/web.xml Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/index.html Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/WEB-INF/faces-config.xml ***SUCCESS*** Installed [forge.spec.jsf] successfully. ***SUCCESS*** Scaffolding installed. No scaffold type was provided, use Forge default? [Y/n] y Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/WEB-INF/beans.xml Wrote /forge-1.0.0.Alpha2/MyApp/src/main/java/org/jboss/seam/forge/persistence/DatasourceProducer.java Wrote /forge-1.0.0.Alpha2/MyApp/src/main/java/org/jboss/seam/forge/persistence/PersistenceUtil.java Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/resources/forge-template.xhtml Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/resources/forge.css Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/resources/favicon.ico ***INFO*** [/forge-1.0.0.Alpha2/MyApp/src/main/java/com/myapp/domain/Person.java] File exists, re-run with `--overwrite` to replace existing files. Wrote /forge-1.0.0.Alpha2/MyApp/src/main/java/com/myapp/view/PersonBean.java Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/scaffold/person/view.xhtml Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/scaffold/person/create.xhtml Wrote /forge-1.0.0.Alpha2/MyApp/src/main/webapp/scaffold/person/list.xhtml ***SUCCESS*** Generated UI for [com.myapp.domain.Person]

Open Eclipse (with m2eclipse installed)

Choose File > Import > Existing Maven Projects and import the pom.xml at \forge-1.0.0.Alpha2\MyApp\pom.xml
Edit src/main/resources/META-INF/persistence.xml and remove the line that says <non-jta-data-source/>

Right click the pom.xml and choose Run As > Maven package

Take the WAR it generates under target/MyApp-1.0.0-SNAPSHOT.war and deploy it under JBoss AS 6.0.0.Final

Open your browser at http://localhost:8080/MyApp-1.0.0-SNAPSHOT/scaffold/person/list.jsf:
Click Create:

And that's it! Seam Forge has created a full web application for you, complete with JPA back-end and JSF front-end, without you having to write a single line of code. Of course there's much more to it than that, but hopefully this gives you a taste for what JBoss and the Seam Team are cooking up!

MySQL Performance: Leveraging SQL_CALC_FOUND_ROWS and FOUND_ROWS inside JPA-QL

2011-03-07T18:14:00.020+11:00

There are lots of articles on the Web about how to optimize paginated displays. The basic problem is: in order to paginate well, you must display the total number of hits to the user:

1...30 (of 54,342)

But finding that total number of hits can be slow. In particular doing select count(*) in MySQL is notoriously slow. There are lots of possible solutions. A promising, MySQL-specific one is select FOUND_ROWS(). Using this via native SQL is easy. But exposing it inside JPA-QL (which generates its SQL automatically) is tricky. The rules for using it are:

Clients must run a normal query, using LIMIT for pagination, and prefix it as: select SQL_CALC_FOUND_ROWS * from myTable

Immediately afterwards, before any other SQL statements are run, clients call select FOUND_ROWS() to obtain the number of rows there would have been if no LIMIT had been set

A further advantage of SQL_CALC_FOUND_ROWS is that it can be used with having queries, whereas count() cannot.

Here's one way to leverage this inside Hibernate-based JPA. We'll be using Interceptors. Like all the solutions to this problem, this one isn't perfect, but it may suit your purposes:

package com.kennardconsulting.core.hibernate.interceptor; import org.hibernate.EmptyInterceptor; import org.hibernate.HibernateException; import org.hibernate.SessionFactory; /** * Hibernate interceptor to make use of MySQL's proprietary <code>SQL_CALC_FOUND_ROWS</code> hint. * The <code>count()</code> method in MySQL is notoriously slow * (http://mysqlha.blogspot.com/2009/08/fast-count-for-innodb.html) as it scans the entire index. * <code>SQL_CALC_FOUND_ROWS</code> was introduced to allow clients to obtain a <code>count()</code> * in a more performant way. * <p> * The rules are: * <p> * <ol> * <li>Clients must run a normal query, using <code>LIMIT</code> for pagination, and prefix it with * <code>SQL_CALC_FOUND_ROWS</code></li> * <li>Immediately afterwards, <em>before any other SQL statements are run</em>, clients call * <code>FOUND_ROWS()</code> to obtain the number of rows there <em>would</em> have been, if no * limit had been set</li> * </ol> * <p> * A further advantage of <code>SQL_CALC_FOUND_ROWS</code> is that it can be used with * <code>having</code>, where <code>count()</code> cannot. * <p> * Other approaches we tried: * <p> * <ul> * <li>Hibernate supports ScrollableResults, but on MySQL that seems to just bring back the entire * results and is very slow</li> * <li>You can try embedding count(*) as an extra column in the query, but that negates the indexes</li> * <li>You can try 'show table status where name = Member' but that varies wildly and is * disconcerting for the user (for 60,000 rows, +/- 3,000 rows)</li> * <li>You can make 'count()' setCacheable( true )</li> * </ul> * <strong>Note: this is not a general purpose Interceptor. It assumes it will be used to execute a * single select (possibly with secondary selects) and then thrown away. It cannot be * re-used.</strong> */ public class MySQLCalcFoundRowsInterceptor extends EmptyInterceptor { // // Private statics // private final static String SELECT_PREFIX = "select "; private final static String CALC_FOUND_ROWS_HINT = "SQL_CALC_FOUND_ROWS "; private final static String SELECT_FOUND_ROWS = "select FOUND_ROWS()"; // // Private members // private SessionFactory mSessionFactory; private byte mSQLStatementsPrepared; private Long mFoundRows; // // Constructor // public MySQLCalcFoundRowsInterceptor( SessionFactory sessionFactory ) { mSessionFactory = sessionFactory; } // // Public methods // @Override public String onPrepareStatement( String sql ) { switch ( mSQLStatementsPrepared ) { case 0: { mSQLStatementsPrepared++; // First time, prefix CALC_FOUND_ROWS_HINT StringBuilder builder = new StringBuilder( sql ); int indexOf = builder.indexOf( SELECT_PREFIX ); if ( indexOf == -1 ) { throw new HibernateException( "First SQL statement did not contain '" + SELECT_PREFIX + "'" ); } builder.insert( indexOf + SELECT_PREFIX.length(), CALC_FOUND_ROWS_HINT ); return builder.toString(); } case 1: { mSQLStatementsPrepared++; // Before any secondary selects, capture FOUND_ROWS. If no secondary selects are // ever executed, getFoundRows() will capture FOUND_ROWS just-in-time when called // directly captureFoundRows(); return sql; } default: // Pass-through untouched return sql; } } public long getFoundRows() { if ( mFoundRows == null ) { captureFoundRows(); } return mFoundRows; } // // Private methods // private void captureFoundRows() { // Sanity checks if ( mFoundRows != null ) { throw new HibernateException( "'" + SELECT_FOUND_ROWS + "' called more than once" ); } if ( mSQLStatementsPrepared < 1 ) { throw new HibernateException( "'" + SELECT_FOUND_ROWS + "' called before '" + SELECT_PREFIX + CALC_FOUND_ROWS_HINT +"'" ); } // Fetch the total number of rows mFoundRows = ( (Number) mSessionFactory.getCurrentSession().createSQLQuery( SELECT_FOUND_ROWS ).uniqueResult() ).longValue(); } }

To use this Interceptor inside JPA-QL:

SessionFactory sessionFactory = ((org.hibernate.Session) mEntityManager.getDelegate()).getSessionFactory(); MySQLCalcFoundRowsInterceptor foundRowsInterceptor = new MySQLCalcFoundRowsInterceptor( sessionFactory ); Session session = sessionFactory.openSession( foundRowsInterceptor ); try { org.hibernate.Query query = session.createQuery( ... ) // Note: JPA-QL, not createNativeQuery! query.setFirstResult( ... ); query.setMaxResults( ... ); List entities = query.list(); long foundRows = foundRowsInterceptor.getFoundRows(); ... } finally { // Disconnect() is good practice, but close() causes problems. Note, however, that // disconnect could lead to lazy-loading problems if the returned list of entities has // lazy relations session.disconnect(); }

Hope that helps!

Eclipse Helios: Missing semicolon JavaScript Warnings

2011-03-03T10:21:00.009+11:00

If your Eclipse Problems tab looks like this after upgrading to 3.6.2 (Helios)...
...and you're having a hard time turning that off, here's what appears to be the answer:

The Suspend all validators checkbox on the Window > Preferences > Validation screen is broken (or partially broken, its behaviour is a bit erratic). So ignore it.

Instead, uncheck that box (and leave it unchecked) and explictly turn off Client-side Javascript validation in the box underneath:

Hope that helps somebody! I've reported this as bug 338759.

Metawidget and Drools

2011-03-01T21:11:00.013+11:00

Blogger Sergiy has put together a terrific example of integrating Metawidget with JBoss Drools.

He uses Metawidget to render a Drools ViewDefiniton for use in a weather forecasting application. To quote:

"One of the key aspects of Metawidget is its concept of inspectors that are responsible for extracting meaningful metadata from business objects. Metawidget comes with a number of default inspectors that allow extracting metadata based on Java reflection, annotations, etc. But what if we want something special? :)

For instance, how about using business rules as the source of meaningful metadata for a UI?"
He then describes in detail the steps necessary to create an application like this:

Read the full blog post here.

Thanks Sergiy!

User Interface Generation Tools: JAXenter Metawidget interview

2011-02-24T12:02:00.004+11:00

I did a short interview with JAXenter about the recent v1.10 release of Metawidget, the user interface generation tool.

Thanks for the shout-out guys!

JAXenter have previously done an in-depth article on Metawidget here.

User Interface Generation: Metawidget v1.10

2011-02-10T20:57:00.003+11:00

Version 1.10 of Metawidget, the user interface generation tool is now available! This release includes the following enhancements:

PrimeFaces support
Improved ICEfaces support
JpaInspector.setHideVersions
Refactored GWT StyleNameProcessor
JSF2 version of AddressBook
Upgrade to Seam 2.2.1.GA
Bug fixes, documentation and unit tests

As always, the best place to start is the Reference Documentation:

http://metawidget.org/doc/reference/en/pdf/metawidget.pdf

Special thanks to Ronald van Kuijk and Leon E for their help with this release!

Your continued feedback is invaluable to us. Please download it and let us know what you think.

Metawidget: PrimeFaces TabView support

2011-02-08T20:40:00.012+11:00

In a similar fashion to my previous blog, the next release of Metawidget (v1.10) will add support for the PrimeFaces TabView component.

I have updated the AddressBook Example included in the distribution to demonstrate swapping in PrimeFaces support. So now you can add...

<metawidget> ... <layout> <tabViewLayoutDecorator xmlns="java:org.metawidget.faces.component.html.layout.primefaces" config="org.metawidget.layout.decorator.LayoutDecoratorConfig"> <layout> <simpleLayout xmlns="java:org.metawidget.faces.component.layout"/> </layout> </tabViewLayoutDecorator> </layout> </metawidget>

...and you auto-magically get (note the PrimeFaces TabView and the PrimeFaces Slider)...

Early access code now available in SVN.

Metawidget: ICEfaces PanelTabSet support

2011-02-08T16:48:00.010+11:00

The next release (v1.10) of Metawidget improves our ICEfaces support by adding PanelTabSetLayoutDecorator. So now you can do:

<metawidget> ... <layout> <panelTabSetLayoutDecorator xmlns="java:org.metawidget.faces.component.html.layout.icefaces" config="org.metawidget.layout.decorator.LayoutDecoratorConfig"> <layout> <simpleLayout xmlns="java:org.metawidget.faces.component.layout"/> </layout> </panelTabSetLayoutDecorator> </layout> </metawidget>

I have updated the ICEfaces PenguinColony Example included in the distribution to include tabs inside the dialog:
The full ICEfaces AJAX experience of dynamically creating components still works as normal inside the tabs:

Early access code now available in SVN.

Cluster Ointment: JBoss, JGroups and Shunning

2011-02-07T17:31:00.009+11:00

For some months now we've been having intermittent problems with our JBoss cluster. Whenever a cluster node died and restarted, sometimes it would fail to rejoin the cluster. The log would just keep saying:

WARN [org.jgroups.protocols.pbcast.GMS] join(<IP address>) sent to <IP address> timed out (after 3000 ms), retrying WARN [org.jgroups.protocols.pbcast.GMS] join(<IP address>) sent to <IP address> timed out (after 3000 ms), retrying WARN [org.jgroups.protocols.pbcast.GMS] join(<IP address>) sent to <IP address> timed out (after 3000 ms), retrying WARN [org.jgroups.protocols.pbcast.GMS] join(<IP address>) sent to <IP address> timed out (after 3000 ms), retrying

This happened on JBoss 4.0.3, 4.2, 5.0 and 5.1. But today I found some interesting tidbits:

When a [JGroups] member [defined by its IP and port number] is expelled from the group, e.g. because it didn't respond to are-you-alive messages, and later comes back, then it is shunned (source)
JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically) increasing across a single machine... [but this may not hold] for TCP ... because we're defining the start_port for a member, and so that member will always reuse the same port when restarted [the term is 'reincarnated'] (source)

In [JGroups] 2.8, shunning has been removed, so the sections below only apply to versions up to 2.7 (source)

So any version of JBoss using JGroups 2.7 or earlier (which includes JBoss 5.1) will see this problem if you're explictly defining the start_port for a node. The solution is to edit jgroups-channelfactory-stacks.xml:

<FD_SOCK/> <FD timeout="6000" max_tries="5" shun="false"/> <VERIFY_SUSPECT timeout="1500"/> <pbcast.NAKACK use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800" discard_delivered_msgs="true"/> <UNICAST timeout="300,600,1200,2400,3600"/> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="400000"/> <pbcast.GMS print_local_addr="true" join_timeout="3000" shun="false" reject_join_from_existing_member="false" view_bundling="true" view_ack_collection_timeout="5000"/>

This has shown an immediate improvement in our cluster. Hope it works for you too!

Metawidget: Defining Business Objects Using Maps (JSF Version)

2011-02-02T13:35:00.008+11:00

I thought I'd do a JSF 2 version of my previous blog entry. Doing it in JSF is a litte more difficult to grok, because the all important methods...

metawidget.setToInspect( values ); metawidget.setPath( "person" );

...are obscured behind JSF's standard syntax:

<m:metawidget value="#{...}"/>

There are a number of ways you could unobscure them, but so as not to be confusing I'll just talk about one here. Basically I will wrap the 'toInspect' values and the 'path' type in MyManagedBean so that I can pass them both in a single ValueExpression:

<m:metawidget value="#{myManagedBean}"/>

Regardless, the crucial point - as with the Swing version - is that there's a MapInspector and a MapWidgetProcessor and they operate on different Maps.

You can download the complete project here.

Metawidget: Defining Business Objects Using Maps

2011-02-02T12:00:00.007+11:00

I was recently asked whether Metawidget could inspect, load and save business objects based not on a JavaBean (or GroovyBean, ScalaBean etc) but on a Map of names and attributes. The answer is yes!

I've sort of covered this before but last time I only blogged about inspecting the Map, not loading and saving the values.We already have a GWT version of this in the Metawidget distribution (see the GWT Client Side example) but now I've put together a Swing project you can download too. It's very similar to the previous blog but adds a MapWidgetProcessor that loads and saves values back into a Map.

An important point to grok is that the 'Map of properties' (used by MapInspector) is different to the 'Map of values' (used by MapWidgetProcessor). This is in the same way that a 'Class' is different to an 'Object': one defines the type, one defines the instance values. So in the code you will see:

metawidget.setToInspect( values ); metawidget.setPath( "person" );

We call both setToInspect (to tell Metawidget where the values are coming from) and setPath (to tell Metawidget what the type is). Normally when using a JavaBean (or GroovyBean, ScalaBean etc) you don't need to do this, because Metawidget will internally call...

metawidget.setPath( metawidget.getToInspect().getClass() )

...on your behalf. But if you want to start using Maps, these two concepts need to be explictly separate.

Take a look for yourself here. Or, for the impatient, here's the most important piece of code:

/** * MapWidgetProcessor uses the Metawidget's <code>toInspect</code> to retrieve/store values. */ public class MapWidgetProcessor implements AdvancedWidgetProcessor<JComponent, SwingMetawidget> { // // Public methods // @Override public void onStartBuild( SwingMetawidget metawidget ) { getWrittenComponents( metawidget ).clear(); } /** * Retrieve the values from the Map and put them in the Components. */ @Override public JComponent processWidget( JComponent component, String elementName, Map<String, String> attributes, SwingMetawidget metawidget ) { String attributeName = attributes.get( NAME ); getWrittenComponents( metawidget ).put( attributeName, component ); // Fetch the value... Map<String, Object> toInspect = metawidget.getToInspect(); Object value = toInspect.get( attributeName ); if ( value == null ) { return component; } // ...and apply it to the component. For simplicity, we won't worry about converters String componentProperty = metawidget.getValueProperty( component ); ClassUtils.setProperty( component, componentProperty, value ); return component; } @Override public void onEndBuild( SwingMetawidget metawidget ) { // Do nothing } /** * Store the values from the Components back into the Map. */ public void save( SwingMetawidget metawidget ) { Map<String, Object> toInspect = metawidget.getToInspect(); for ( Map.Entry<String,JComponent> entry : getWrittenComponents( metawidget ).entrySet() ) { JComponent component = entry.getValue(); String componentProperty = metawidget.getValueProperty( component ); Object value = ClassUtils.getProperty( component, componentProperty ); toInspect.put( entry.getKey(), value ); } } // // Private methods // /** * During load-time we keep track of all the components. At save-time we write them all back * again. */ private Map<String,JComponent> getWrittenComponents( SwingMetawidget metawidget ) { @SuppressWarnings( "unchecked" ) Map<String,JComponent> writtenComponents = (Map<String,JComponent>) metawidget.getClientProperty( MapWidgetProcessor.class ); if ( writtenComponents == null ) { writtenComponents = CollectionUtils.newHashMap(); metawidget.putClientProperty( MapWidgetProcessor.class, writtenComponents ); } return writtenComponents; } }

Metawidget: PrimeFaces support

2011-01-28T22:29:00.004+11:00

The guys over at Activiti recently expressed an interest in integrating Metawidget into their BPM product. They had a few concerns, most notably PrimeFaces support, so I thought I'd have a go at implementing it.

I'm delighted to say that, thanks to PrimeFaces' solid build quality and outstanding User Guide (over 400 detailed pages!) integration went very smoothly. There were a few minor glitches related to Mojarra which I will be working with that team to get resolved. But MyFaces works great.

I have checked the code into SVN ready for the Metawidget v1.10 release. I have also put together a sample project demonstrating PrimeFaces support which you can download here.

HttpClient 4: Want To Make It 250x Faster?

2011-01-27T13:59:00.016+11:00

I just spent a few hours debugging a performance problem with my app. It came down to a default setting inside Apache HttpClient 4.0.3.

Don't get me wrong, HttpClient is an awesome piece of work and a fantastic contribution to the community - I use it in lots of my projects and it's very useful. So my thanks to the HttpClient team for all their hard work.

However, by default HttpClient 4.0.3 adds a...

Expect: 100-continue

...header to every POST request. This appears to interact badly with Tomcat's (and JBoss', and possibly other containers) FormAuthenticator. Specifically somewhere around...

request.getParameter( Constants.FORM_USERNAME )

...FormAuthenticator disappears into a hole (during Request.parseParameters) for some 2 seconds before emerging with the parameters. It appears to be 'lazy loading' the request body during this time? According to the HTTP spec the header "allows a client that is sending a request message with a request body to determine if the origin server is willing to accept the request before the client sends the request body".

If you're using HttpClient to log in to your Java EE server (say, for black box testing) this can be a significant performance hit. Removing the Expect header logs you in in about 8ms, some 250 times faster.

You can remove the Expect header by doing:

client.removeRequestInterceptorByClass( RequestExpectContinue.class );

I've put together a sample WAR to reproduce the problem, along with deployment instructions, under this issue here.

Update: it appears this is actually a bug in Tomcat 6. Now tracking under this issue here.

Metawidget: Dynamic Layouts

2011-01-19T13:10:00.010+11:00

I was recently asked whether Metawidget can change layouts dynamically, say from a tab-based layout to a panel-based layout?

The answer is yes! You can call...

metawidget.setLayout( myLayout );

...at any time to dynamically update the layout. The questioner was asking in relation to JSF, and the hardest bit in JSF is actually getting programmatic access to the Metawidget. This requires the binding attribute I've blogged about previously.

But once past that, you can put together something like this:

Note the buttons at the buttom that allow you to select which layout to use. I have put together the complete project you can download from here.

Grokking Seam Forge: Part 1

2011-01-03T11:01:00.010+11:00

JBoss have just released Alpha 1 of Seam Forge, their framework for rapid-application development that includes Metawidget support.

You can read more about the release and how to use it here. After that, for those wanting to dive into the code (either out of curiosity or to start contributing) here's a step-by-step guide that may save some trial and error:

Install JBoss Tools

Download Eclipse 3.5 SR2 (just the 'Eclipse IDE for Java Developers' version)

Download JBoss Tools 3.1.GA

Unzip Eclipse, and run eclipse.exe

Select a workspace (I'd recommend starting a new one)

Use Help > Install New Software. Click Add then Archive (see screenshot):
Click OK

Check All JBoss Tools - 3.1.1. Click Next and Next again

Choose I accept the terms of the license agreements and click Finish
(NB. there seems to be a bug here: the Finish button will not always be enabled? I found clicking back to the start of the wizard fixed it)

Wait for the install to complete. Accept any signing certificates. Restart the IDE

Install EGit

Use Help > Install New Software and click Add

Enter a Location of http://download.eclipse.org/egit/updates (see screenshot):
Check Eclipse Git Team Provider. Click Next

Click Finish

Wait for the install to complete. Accept any signing certificates. Restart the IDE

Clone the Seam Forge Repository

Use File > Import and choose Projects from Git (see screenshot):
Click Clone... and enter a URI of git://github.com/seam/forge.git (see screenshot):
Click Next, choose the Master branch, click Next (see screenshot):
Click Finish. Wait for the Git repository to clone (may take a while). See screenshot:
Click Cancel (not Next!)

Install Maven

Use Help > Install New Software

Choose to Work with the 'Maven Integration for Eclipse Update Site'

Check the 'Maven Integration for Eclipse' box (see screenshot):
Click Next, Next, accept the license terms and Finish

Wait for the install to complete. Accept any signing certificates. Close the IDE (don't restart it)

Edit eclipse/eclipse.ini and add the lines in bold:
--launcher.XXMaxPermSize 256m -vm <path to your JDK>\bin\javaw.exe -vmargs -Dosgi.requiredJavaVersion=1.5

(Maven needs Eclipse running under a JDK, not a JRE)

Relaunch the IDE

Import Maven Projects

Use File > Import. Choose Maven > Existing Maven Projects (see screenshot):
Browse to the location of the Git clone (see screenshot):
Click Finish. Wait for import of Maven projects (may take a while)

All Seam Forge sub-projects should now be listed under the Package Explorer. There should be no compile errors under the Problems tab, though there may be warnings (as this is still an alpha release). See screenshot:

We're Hiring Again!

2010-12-28T13:08:00.001+11:00

Here's the job ad we're posting. Following a successful first hire earlier this year, and increased investment from a leading Australian financial institution, we're hiring again. A chance to work from home, and work for me! What a dream job :)

Senior Java EE 5 (J2EE) Developer: $120,000 AUD + super

Small, focused team

Modern, well-crafted software

Work in city or from home

A rare opportunity to join our small consultancy team. We have recently received substantial investment from a leading Australian financial institution and we must grow to meet demand.

You will work side-by-side with one of Australia's premier Java EE developers, and be intimately involved in all design decisions.

You will be a pragmatic programmer. Software development will be in your blood: a natural instinct. You must be passionate about Open Source and Java EE. You will demonstrate advanced analytical skills; an eye for elegance and craftmanship; a passion for refactoring, unit testing, and delivering secure and robust code.

Your skills will include many of the following:

JBoss

JSF/RichFaces

XSL (T and FO) and XPath

EJB 3/JMS

JPA/SQL

Metawidget

HtmlUnit

HTML/CSS

In addition, you will have excellent communication skills and be comfortable interacting with stakeholders at all levels.

Work from home will be offered providing that you can demonstrate an appropriate working environment. You must be a citizen or permanent resident of Australia.

To help us sort applicants, include your CV and a 1 page overview highlighting your suitability for the role. Links to examples of your work (eg. web sites you have built, blogs you have written, Open Source contributions etc) will be highly regarded.

Please send your application to jobs@kennardconsulting.com.

Retrofitting a UI: GatewayWarDeployment example

2010-12-17T12:20:00.028+11:00

Adam Bien recently asked me to create a Metawidget example for his Java EE Patterns and Best Practices Kenai Repository, based on his Real World Java EE Patterns book.

In order to demonstrate the changes typically required to incorporate Metawidget into a project (and the code savings it typically brings) I retrofitted one of Adam's original projects, his GatewayWarDeployment example. I've called mine GatewayWarDeploymentWithMetawidget.

To view the new example:

Ensure you have Metawidget installed at its default location (/metawidget-1.05/metawidget.jar)

Get sources for the Java EE Patterns Kenai project in NetBeans using Team > Team Server > Get Sources... (see this screencast for detailed instructions)
Open the GatewayWarDeploymentWithMetawidget project

The example works just as before, but two files have been changed. The first is the managed bean, LoadView.java, which now includes Metawidget annotations and is therefore longer. The second is the UI page, createorder.xhtml, which now uses a <m:metawidget> tag and is therefore shorter:

LoadView.java	createorder.xhtml

In such a small example there is no overall saving in lines of code (larger examples have more dramatic savings). But there is still a significant reduction in duplicated declarations (field names, types, action names etc) and therefore reduced possibility of error when building (and maintaining) the UI. Note Metawidget is handling both the input boxes and the buttons, including enabling/disabling the buttons in line with the business logic. This is declared by the code:

@UiAction @UiFacesAttribute( name = "read-only", expression = "#{load.emptyLoad}" ) public void dropLightest(){ ... }

Of course, this is not a great demonstration of all the features of Metawidget. More extensive examples can be found under the /examples folder of the Metawidget distribution. But hopefully it's enough to get people excited without confusing them with lots of code.

My thanks to Adam for his help and encouragement in developing this example!

Automatic Form Generator: Metawidget v1.05

2010-12-15T20:12:00.005+11:00

Version 1.05 of Metawidget, the automatic form generator is now available! This release includes the following enhancements:

Improved JSF 2 support (Mojarra 2.1 and MyFaces 2.0.3)
Support for annotating private fields
char support
JSF2 AjaxProcessor
Read-only actions now display as disabled buttons (rather than not displaying at all)
Bug fixes, documentation and unit tests

SeamForge: Latest Update

2010-12-14T07:31:00.000+11:00

I'm growing a little uncomfortable with the direction SeamForge is taking. Here's an output from the latest build:

$ forge ____ _____ / ___| ___ __ _ _ __ ___ | ___|__ _ __ __ _ ___ \___ \ / _ \/ _` | '_ ` _ \ | |_ / _ \| '__/ _` |/ _ \ \\ ___) | __/ (_| | | | | | | | _| (_) | | | (_| | __/ // |____/ \___|\__,_|_| |_| |_| |_| \___/|_| \__, |\___| |___/ [no project] $ new-project Greetings, Professor Falken. Would you like to play a game?

Rant: Who Designs These UI Frameworks Anyway?

2010-12-01T19:02:00.016+11:00

I started a lively discussion over on Javalobby ranting about UI framework APIs.

Specifically: how come hardly any UI frameworks define their widgets in terms of interfaces, as opposed to abstract base classes? I listed off a dozen mainstream UI frameworks that do this, and was fortunate to get dozens of people responding with their thoughts. The key outcomes were:

Some UI frameworks (albeit a minority) are interface-based. Examples include ItsNat, Vaadin
Other frameworks have considered being interface-based (Swing), but on balance decided to use abstract classes. Neither is optimal: "when I was working on the Swing team at Sun Microsystems back in the early days of Java. Some people on the team were of the opinion that Component should be an interface and others that it was best as an abstract class. But really, neither sounded like a good choice"
Abstract base classes limit future use cases. This is dangerous because "anything of strategic importance will be used in ways that the original designer cannot anticipate"
The problem with a 'monolithic' interface is that it is cumbersome to evolve: "You will soon have IComponent, IComponent_v2, IComponent_v3"
The problem with 'granular' interfaces is that you often have to pass around many of them together: "I found it to get problematic as I'd pass around something like (Sizable, Locatable) and then deep in the heart of the framework I realised I needed Focusable also, and I then had to go back up the stack chain and add it to all parameters"
Java does not have a good way to bundle several 'granular' interfaces together, but other languages may (Scala traits): "It's not yet possible to write Component the way I really want to write it. To do that, you'd have to change Java."

Finally, I would like to apologise to any who were offended by the somewhat incendiary tone of my article. It was pitched as a 'rant' in order to encourage responses, but in no way was I suggesting the UI frameworks I listed were anything but successful - or that their creators were anything but intelligent, brilliant people.

Metawidget: Collections Support Part 2 (More Advanced)

2010-11-25T15:19:00.006+11:00

In my last post I looked at some quirks of using the ICEfaces PanelTabSet with Metawidget. Specifically, because PanelTabSet stores the selectedIndex of the current tab inside the component, the component cannot succesfully be destroyed and recreated.

To work around this we looked at using Metawidget's COMPONENT_ATTRIBUTE_NOT_RECREATABLE to preserve the selectedIndex at the expense of some dynamicism. We further looked at using JSF's binding attribute to try and claw back some of that dynamicism.

However, a different approach entirely would be to stop PanelTabSet storing selectedIndex internally! It turns out ICEfaces provides an API for this. The only question is where else to store selectedIndex, but keeping it inside the current request seems to work nicely. So:

Forget all about COMPONENT_ATTRIBUTE_NOT_RECREATABLE and the binding attribute (and related mMetawidget inside the managed bean)

Change the line in the IceFacesTabsWidgetBuilder that says...

panelTabSet.getAttributes().put( UIMetawidget.COMPONENT_ATTRIBUTE_NOT_RECREATABLE, true );

...to say...

panelTabSet.setValueExpression( "selectedIndex", expressionFactory.createValueExpression( elContext, "#{param['tab-" + attributes.get( NAME ) + "']}", Object.class ) );

So now you get fully dynamic tabs at the same time as tab switching working! This technique only applies in those cases where the UIComponent thoughtfully exposes such an API, but in such cases it's very useful.

Hope that helps!

Metawidget: Collections Support Part 2 (Advanced)

2010-11-24T11:16:00.015+11:00

In my previous post, I showed how to render a Collection as one item per tab. This is pretty easy in most frameworks, but ICEfaces presents a challenge because:

The ICEfaces PanelTabSet doesn't have an option to switch tabs on the client-side, using just JavaScript and CSS to show/hide the tabs (RichFaces has switchType="client")

The ICEfaces PanelTabSet stores its tab state inside the component, so when doing server-side switching you cannot destroy and recreate the component or the tabs won't switch

In my last post I resolved this by setting COMPONENT_ATTRIBUTE_NOT_RECREATABLE on the PanelTabSet. I noted this would allow the user to switch tabs, at the expense of making the tabs themselves less dynamic. But a couple people wanted to know how to get the best of both worlds: how to switch tabs and have them be dynamic.

There are a few answers to this question:

There is still quite a lot of dynamicism, even with COMPONENT_ATTRIBUTE_NOT_RECREATABLE set. Metawidget is smart enough to work around the COMPONENT_ATTRIBUTE_NOT_RECREATABLE components, and still recreates their siblings and even their children. As the project from the previous post shows, you can have an 'Edit' button that makes the components (both inside and outside the tab) turn from read-only labels into input boxes

The COMPONENT_ATTRIBUTE_NOT_RECREATABLE only applies during POST requests. Re-rendering the page afresh as a GET request works fine. So if your user clicks a link to navigate into the page with the TabPanelSet on it, no problem

But there is a further case: what if I want to be able to add tabs with a POST request? Here we need something new. We need to be able to tell Metawidget: don't recreate the tabs normally (else we won't be able to switch between them), but do recreate them when I click 'add tab'.

I have put together a complete project you can download from here. It'll produce something that looks like this:

The trick is to use JSF's binding attribute. As I blogged previously, this is a little-used but very useful feature of JSF that allows programmatic control over your components. So in your page you do:

<m:metawidget value="#{headerDemo}" binding="#{headerDemo.metawidget}"/>

And in your managed bean you do:

public UIMetawidget getMetawidget() { return mMetawidget; } public void setMetawidget( UIMetawidget metawidget ) { mMetawidget = metawidget; } @UiAction @UiComesAfter( "details" ) public void addTab() { mDetails.add( new Detail( mDetails.size(), "Detail #" + mDetails.size() ) ); mMetawidget.getChildren().clear(); }

Hope that helps!

Metawidget: Collections Support Part 2

2010-11-19T08:55:00.006+11:00

I was recently asked:

"I would like to create a widget that displays each item contained in a List using an ICEfaces PanelTabSet. I would like the widget inside each panelTab to be generated through Metawidget. How can I accomplish this?"

This represents (yet) another aesthetic preference for rendering Collections. Namely, rendering one item per tab. Some other preferences, such as rendering one item per row of a table, have been covered in a previous blog entry). As I said in that entry:

To support this, Metawidget provides WidgetBuilders.

So it's a case of writing a WidgetBuilder that will return a PanelTabSet for the List. I have put together a complete project you can download here. It'll produce something that looks like this:

Code for the WidgetBuilder part below:

package com.myapp; import static org.metawidget.inspector.InspectionResultConstants.*; import java.util.List; import java.util.Map; import javax.el.ELContext; import javax.el.ExpressionFactory; import javax.el.ValueExpression; import javax.faces.component.UIComponent; import javax.faces.context.FacesContext; import org.metawidget.faces.FacesUtils; import org.metawidget.faces.component.UIMetawidget; import org.metawidget.faces.component.UIStub; import org.metawidget.faces.component.html.HtmlMetawidget; import org.metawidget.util.ClassUtils; import org.metawidget.util.simple.StringUtils; import org.metawidget.widgetbuilder.iface.WidgetBuilder; import com.icesoft.faces.component.paneltabset.PanelTab; import com.icesoft.faces.component.paneltabset.PanelTabSet; public class IceFacesTabsWidgetBuilder implements WidgetBuilder<UIComponent, UIMetawidget> { // // Public methods // @Override public UIComponent buildWidget( String elementName, Map<String, String> attributes, UIMetawidget metawidget ) { // Not for us? String type = attributes.get( TYPE ); if ( type == null ) { return null; } Class<?> clazz = ClassUtils.niceForName( type ); if ( !List.class.isAssignableFrom( clazz ) ) { return null; } // Create a Stub to wrap around the PanelTabSet. // // This is because: // // 1. PanelTabSet will not switch tabs if it is destroyed/recreated. We must set // COMPONENT_ATTRIBUTE_NOT_RECREATABLE on it (see // http://metawidget.sourceforge.net/doc/reference/en/html/ch02s04.html#section-architecture-widgetbuilders-implementing-your-own-faces). // This limits some dynamicism, such as being able to dynamically add tabs, but there are // further ways around that // // 2. COMPONENT_ATTRIBUTE_NOT_RECREATABLE only works if there is a 'value' expression that // OverriddenWidgetBuilder can match against // // 3. PanelTabSet is a little unusual in how it treats its 'value' expression (binding it to // a UI mechanism, rather than a model mechanism) so we need to avoid using it. We use the // Stub's 'value' expression instead UIStub stub = new UIStub(); FacesContext context = FacesContext.getCurrentInstance(); ELContext elContext = context.getELContext(); ValueExpression metawidgetValueExpression = metawidget.getValueExpression( "value" ); String metawidgetValueExpressionString = FacesUtils.unwrapExpression( metawidgetValueExpression.getExpressionString() ); ExpressionFactory expressionFactory = context.getApplication().getExpressionFactory(); String tabSetValueExpressionString = metawidgetValueExpressionString + StringUtils.SEPARATOR_DOT_CHAR + attributes.get( NAME ); ValueExpression tabSetValueExpression = expressionFactory.createValueExpression( elContext, FacesUtils.wrapExpression( tabSetValueExpressionString ), Object.class ); stub.setValueExpression( "value", tabSetValueExpression ); // Create tab set PanelTabSet panelTabSet = new PanelTabSet(); panelTabSet.getAttributes().put( UIMetawidget.COMPONENT_ATTRIBUTE_NOT_RECREATABLE, true ); stub.getChildren().add( panelTabSet ); List<UIComponent> tabs = panelTabSet.getChildren(); // Lookup the List from the parent Metawidget to see how many items it has List<?> list = (List<?>) tabSetValueExpression.getValue( elContext ); // Create one tab per item... for ( int loop = 0, length = list.size(); loop < length; loop++ ) { PanelTab tab = new PanelTab(); tabs.add( tab ); // ...with each tab itself containing a Metawidget. // // The 'value' expression of each Metawidget uses the EL #{foo.bar[0]} notation for // accessing arrays HtmlMetawidget tabMetawidget = new HtmlMetawidget(); ValueExpression tabValueExpression = expressionFactory.createValueExpression( elContext, FacesUtils.wrapExpression( tabSetValueExpressionString + '[' + loop + ']' ), Object.class ); tabMetawidget.setValueExpression( "value", tabValueExpression ); tabMetawidget.setValueExpression( "readOnly", metawidget.getValueExpression( "readOnly" ) ); tab.getChildren().add( tabMetawidget ); } // Return tab set return stub; } }