Friday, December 23, 2011

Forge and Metawidget Discussed On JBoss Community Asylum

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: "'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.

Monday, December 19, 2011

You Can't Spell Forge Without Metawidget

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:inputText id="customerBeanCustomerFirstName" value="#{customerBean.customer.firstName}"/>
      <h:message for="customerBeanCustomerFirstName" styleClass="error"/>

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 =;
if (firstName != null && !"".equals(firstName)) {
   predicatesList.add(<String>get("firstName"), '%' + firstName + '%'));
String lastName =;
if (lastName != null && !"".equals(lastName)) {
   predicatesList.add(<String>get("lastName"), '%' + lastName + '%'));

Please give it a try!
  • Download Forge Beta4

  • Install it

  • Run it

  • Copy and execute this command:
    $ run-url
For the lazy, I've uploaded the project that Forge generates. You can download it here.

Sunday, December 4, 2011

Pleasing Dick Wall

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.

Thursday, December 1, 2011

Metawidget @ JavaOne 2011: JBoss Booth Video

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. A very similar talk, given as a JavaOne conference session, is available on Parleys.

Tuesday, November 8, 2011

Should Have A Higher Level of Abstraction?

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="#{}"/>
<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.

Sunday, October 30, 2011

Metawidget Quotes

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)

Monday, October 10, 2011

Metawidget @ JavaOne 2011 (Epilogue)

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.

Tuesday, September 13, 2011

Metawidget @ JavaOne 2011 (Updated)

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.

Tuesday, August 30, 2011

OIM: Metawidget v1.30

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:

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

Sunday, August 28, 2011

What Good is an OIM?

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 maintenance1, 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"1. 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"1.

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%2. 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"3. 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"1.

3. Generate User Interfaces from Unconventional Sources

Beyond conventional UI generation, the five characteristics of an OIM2 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"4.

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"1.

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"1.

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.

  1. Kennard, R. 2011, 'Adoption Studies'

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

  3. 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.

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

Friday, August 26, 2011

Metawidget 1.25 to 1.30 Migration Guide

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( "#{}'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>

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.

Tuesday, August 23, 2011

Metawidget Moving To GitHub

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

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.

Friday, July 22, 2011

Case Study: Telefónica Health Portal

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 administrationFigure 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">
         <agrupacion codigo="0001">
               <especialidad codigo="01">
                  <nombre>MEDICINA GENERAL</nombre>
                     <acto codigo="0001">
                           ...GP initial consult dynamic fields...
                     <acto codigo="0002">
                           ...GP follow-up visit dynamic fields...
               <especialidad codigo="02">
                     <acto codigo="0001">
                           ...pediatrician initial consult dynamic fields...
                     <acto codigo="0002">
                           ...pediatrician follow-up visit dynamic fields...
               ...more especialidad...
         ...more agrupacion...

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 claimsFigure 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.


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.

Tuesday, July 12, 2011

Metawidget @ JavaOne 2011

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.

Monday, July 11, 2011

Metawidget 1.20 to 1.25 Migration Guide

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:


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:

  1. 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.
  2. 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!

Tuesday, July 5, 2011

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

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 Specifications are:

Connector 1RP SMA Plug (Female pin)
Connector 2RP SMA Jack (Male pin)
Cable Type240 series
Length10 metres
Ohms50 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.

Update: I subsequently ran another 10 metre cable through to the front of the house, and it works equally well. I now get above 90% signal strength everywhere in the house.

Friday, June 24, 2011

3 Out Of 4 Developers Could Benefit From Metawidget

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!

Monday, June 20, 2011

iPad vs Android: Do Consumers Really Want Flash?

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!

Friday, June 17, 2011

Price Gouging and the Asus Eee Pad Transformer

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 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 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.