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

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 JSR-168 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, again.

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 project to the Java Enterprise community on java.net.

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

@Entity
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) {
                this.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.

Figure 1. OpenXava CRUD module for customer

You only need to write the above Customer.java, add it to an existing OpenXava application, redeploy your application to your Java application server, open your browser, and go to http://localhost:8080/Invoicing/xava/module.jsp?application=Invoicing&module=Customer to see the result running.

Creating an OpenXava application from scratch is plain vanilla. Download 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> ant -f CreateNewProject.xml
Buildfile: CreateNewProject.xml
    [input] What is your project name?
Invoicing
    [input] What is the datasource?
InvoicingDS

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 2 of the OpenXava Reference Guide.

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 Invoice:

@Entity                                                         // 1
@View(                                                          // 2
        members=
                "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<InvoiceDetail> details;
        
        @OneToMany(mappedBy="invoice")                          // 5
        private Collection<Delivery> 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. @Entity (JPA): Marks this class as persistent, meaning that there is a table in the database for storing the data of the invoices.

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

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

4. @ManyToOne (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. @OneToMany (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. @ListProperties (OX): You can use this annotation to define the properties display in the user interface for the collection.

7. @Digits: 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 http://localhost:8080/Invoicing/xava/module.jsp?application=Invoicing&module=Customer. No more steps are required.

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.

Conclusion

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

Resources

These frameworks and technologies have the spirit of this article:

• 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 generation you can see the OpenXava documentation.
• 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.)