Skip to main content

Automatic User Interface with OpenXava: An Evolutionary Option for GUIs

June 24, 2008


This is a story about creating a user interface easily, or
better yet, about having good user interfaces without working for

The Problem

Once upon a time, you created a really cool invoicing
application. Your wonderful application had an agile MS-DOS (or
Unix, or AS/400,
or HOST)
character interface, but your users demanded a Windows interface:
more beautiful, and easier to use. So, you rewrote your application
to have a Windows user interface. All OK, but then your users asked you for a multiplatform application, so you rewrote
your application in Java with "">AWT, but your
user interface was poor. Then you rewrote it again using "">Swing.
Again, all OK--or maybe not. The users started to ask for a web
application, so you needed to use "">JSP
to create a web interface--but your users asked for integration
inside portals, so you adapted your application to work inside
portals, and maybe you started to use "">JSF.
And now, your users continue asking for a better user interface;
they demand a richer web interface. Oops! Now you must rewrite
your application using "">AJAX, or
maybe JavaFX,

How many times do you need to rewrite your application in order
to perfect the user interface?

The Solution

The ideal solution, at first glance, is to have a technique to
declare your user interface in an abstract way, and to have several
rendering engines to draw your user interface using various
presentation technologies. This is not a bad idea, and a lot of
good quality attempts in this direction have been created; "">XSL/XML,
XForms, "">XUL, and others are
searching for a abstract way to define user interfaces. But these
techniques are not so abstract. Can you create a Windows
application with XSL/XML? Can you define an Flash application with
XForms? Perhaps. But many times, each new presentation engine has
its own "abstract" user interface definition. In spite of this
comment, I hope that in the near future we have a universal way to
define user interfaces, at least for business applications. Maybe
some evolution of XForms, or ... something.

On the other hand, I advocate an alternate solution: Do
not define "user interface" at all.

Yes, you can create complex business applications without
defining your user interface. How? Simple: you can derive your user
interface from your model; that is, from the classes of your system
that define the structure of the data and the behavior attached to
this data. I've been using this technique for seven years, and I've
noted that the migration from Swing to Web was smooth, and
additionally, the development time has been shortened, since I do
not need to draw user interfaces.

You may think that this technique can only be used for rapid
prototyping or impressive rapid development demos, and that when
you try to create a real-life business application, it will fail.
But this is not true. The trick is in giving the model some tips in
order to lay out the data for the user, or in order to throw some
event in some circumstance. But you do not define the user
interface, you only refine an automatically generated one.

It may help to see an example.

A Simple Example

These examples are based on the "">OpenXava framework, an open source
framework that is a "">federated
to the "">Java Enterprise

For the first example, you can have a class for customer, like this

public class Customer {
        private int number;
        private String name;
        public int getNumber() {
                return number;
        public void setNumber(int number) {
                this.number = number;
        public String getName() {
                return name;
        public void setName(String name) {
       = name;


And from this code, you will obtain an application like the one
in Figure 1 with the complete user interface, plus "">CRUD
behavior and a list mode to browse, order, and filter objects;
generate PDF reports; and export to Excel. You get all this with no
additional code, only the above Customer class.

<br "OpenXava CRUD module for Customer" />
Figure 1. OpenXava CRUD module for customer

You only need to write the above, add it to
an existing OpenXava application, redeploy your application to your
Java application server, open your browser, and go to
to see the result running.

Creating an OpenXava application from scratch is plain vanilla.
the latest version of OpenXava and uncompress it. Then go to the
openxava-3.0.x/workspace/OpenXavaTemplate folder, and
execute the following ant target:

/java/openxava-3.0.2/workspace/OpenXavaTemplate&gt; ant -f CreateNewProject.xml
Buildfile: CreateNewProject.xml
    [input] What is your project name?
    [input] What is the datasource?

As you can see, the build asks you for the project name and for
the datasource. Just type Invoicing and
InvoicingDS. Now you have a new OpenXava project named
Invoicing in your workspace. Go to the src
folder and create the com.mycompany.invoicing.model
package there. Inside it put the code of the above
Customer class. You can deploy this application to a
servlet container using the Ant target deployWar or
using generatePortlets to deploy to a "">JSR-168 portal, such
as Liferay, JetSpeed, or WebSphere Portal. Of course, you have to
define a datasource named InvoicingDS in your
application server. If there are no tables for your classes in
your database, you can use the Ant target updateSchema
for creating or updating the tables in the database.

For a step-by-step guide on creating a new OpenXava project,
see "">Chapter
of the OpenXava "">Reference

A More Complex Example

But what if the case is more complex, such as an invoice, and
automatic GUI generation doesn't seem suitable? Then instead of
defining the user interface for an invoice manually, we can give
the system some clues, and leave it to continue generating the user
interface. For example, you could add "">annotations
to your Invoice class. Let's create an invoice, which
will have a year, number, date, comment, amounts sum, VAT
percentage and VAT, reference to its customer, collection of
details, and collection of deliveries. In order to achieve this, we
need the following classes: Invoice,
Customer, InvoiceDetail, and
Delivery. We already have the code for
Customer, so let's see the code for

@Entity                                                         // 1
@View(                                                          // 2
                "year, number, date;" +
                "comment;" +
                "customer { customer }" +
                "details { details }" +
                "amounts { amountsSum; vatPercentage; vat }" +
                "deliveries { deliveries }"
public class Invoice {                  
        @Column(length=4)                                       // 3
        private int year;

        @Column(length=6)                                       // 3
        private int number;     

        private Date date;

        @Column(length=80)                                      // 3
        private String comment;

        @ManyToOne                                              // 4
        private Customer customer;
        @OneToMany(mappedBy="invoice")                          // 5
        @ListProperties(                                        // 6
                "serviceType, product.description," +
                "product.unitPriceInPesetas, quantity," +
                "unitPrice, amount")                            
        private Collection&lt;InvoiceDetail&gt; details;
        @OneToMany(mappedBy="invoice")                          // 5
        private Collection&lt;Delivery&gt; deliveries;

        // Getters and setters
        // Calculated properties
        @Digits(integerDigits=12, fractionalDigits=2)           // 7
        public BigDecimal getAmountsSum() { ... }
        @Digits(integerDigits=12, fractionalDigits=2)           // 7
        public BigDecimal getVat() { ... }
        @Digits(integerDigits=12, fractionalDigits=2)           // 7
        public BigDecimal getTotal() { ... }


This class does not define the user interface (as would be the
case with XUL or XForm); instead it only gives some information
about the preferred way to layout data. It does so by using
JPA and
OpenXava annotations. Let's examine the annotations:

  1. "">

    (JPA): Marks this class as persistent, meaning that there is a table in the database for storing the data of the

  2. @View
    (OX): With the @View element you define the members
    (properties, references or collections) of the model to show, and
    the distribution of the data in the user interface; using
    {} you indicate the preferred way to classify

  3. "">
    (JPA): @Column is used by the JPA engine
    to obtain information about the database column in order to do the
    , and generating the "">DDL if
    needed. OpenXava uses the length of
    @Column for calculating the size of the editor in the
    user interface.

  4. "">
    (JPA): This is the standard way to define a many-to-one relationship for an entity. That is, a simple reference from
    entity to another. OpenXava uses it for creating the user interface
    for displaying, searching, modifying, and creating new objects of
    the referenced entity.

  5. "">
    (JPA): This annotation is the standard way to
    define an one-to-many relationship for an entity. That is, a
    collection of other entities. OpenXava uses it for creating the
    user interface for managing the collection; this includes viewing
    elements; adding new ones; removing, editing, ordering, and
    searching in the collection; generating PDF reports from the
    collection elements; exporting to Excel; and so on.

  6. "">
    (OX): You can use this annotation to define
    the properties display in the user interface for the

  7. "">
    : This annotation comes from the "">Hibernate Validator framework.
    OpenXava recognizes Hibernate Validator annotations, and in this
    case uses integerDigits and
    fractionalDigits to calculate the size of the user
    interface editors.

From these clues, OpenXava produces a user interface like the one
shown in Figure 2. You only need to write the classes, deploy the
application, and go to
No more steps are required.

<br "OpenXava module for Invoice" />
Figure 2. OpenXava module for Invoice

You can see how this interface is still rendered from the model,
and the OpenXava annotations are only a group of simple abstract
tips. For example, the sections -- members within curly braces --
indicate how the information is related in order to display it. In
this case, each section corresponds to a tab in the user interface,
but another renderer can choose to use trees, or some other UI
control, to access the data of the sections, including showing all
data on the same screen. A particularly powerful renderer could
allow the user to choose the exact way to represent sections (tabs,
trees, or other).

What happens if your data model changes? In this case you only
need to add the properties, references, and collections you want,
and then execute the Ant target updateSchema to update
your database, deploy your application (with
deployWar), and refresh your browser. If you are using
Eclipse for JEE, you can omit the deploy step.


The automatic generation of a user interface from a model is not a
universal solution; sometimes designing a user interface manually
really is the better alternative. But, in many cases, (as in the
case of business applications) a high percentage of the application
user interface can be created automatically, with a really good result.

Automatic UI generation has the following advantages:

  • Interface evolution: Because you do not write the
    interface using a specific technology, the migration of an
    application to another presentation technology is easy (for example,
    moving from a pure HTML application to an AJAX one).

  • Productivity: You free your developers from time-consuming work. At the end, the "">MVC
    frameworks remain MC frameworks.

And the most important issue: this is not a theoretical
approach, it is a pragmatic one. In my company we have been using this
technique for seven years with great satisfaction. First, we have
inexperienced programmers working productively with Java, without
the need to learn the nuances of Swing. We also have the same
programmers developing Web Portal applications without having to
learn JSP, JSF, JSR-168, or other technical stuff.

Do you think that using Swing or JSP or JSF or AJAX is needed
for the happiness of your developers? I think not. When developers
are used to automatic UI generation, they start to hate the
handmade development (even using a GUI builder) of user


These frameworks and technologies have the spirit of this

  • OpenXava: This
    framework automatically generates business applications from
    simple Java classes with annotations, including complex user
    interfaces. The example in this article uses OpenXava syntax. If
    you are interested in the "">complete syntax for UI
    you can see the "">OpenXava
  • Trails generates
    applications from annotated POJOs.
  • JMatter constructs
    workgroup business applications based on model classes.
  • NakedObjects generates a UI from Java objects; classes must follow some rules.
  • RomaFramework generates applications from POJOs using XML files for customizing the view.
  • MDA: The essence of MDA is
    generating a complete application (therefore a UI, too) from a UML
    model. The main element of software design is the model, and the
    user interface is generated. (Maybe the excessive code-generation
    orientation of MDA produces tools that are not agile, from a
    developer perspective.)

width="1" height="1" border="0" alt=" " />
Javier Paniza is the project lead for OpenXava project.
Related Topics >> GUI   |