Javier has posted 49 posts at DZone. View Full User Profile

Model-Driven GUI Generation with OpenXava

  • submit to reddit

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.

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

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.

OpenXava CRUD module for Customer
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?
[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 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
"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.

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


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.)
Published at DZone with permission of its author, Javier Paniza.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mike P(Okidoky) replied on Thu, 2009/05/07 - 12:28pm

I can speak for using strict MVC. I've taken MVC to far stricter levels than you generally see around.

Business logic (controllers) write only to a model, and a completely independent gui hooks in to the model listening for changes.

Controller must never talk to the View.

I take it a step further. I never have the View talk to the Controller. I *always* have the View make its requests back to the Model. The Controller than picks up this request from the Model.

Strictly doing it this way, means the View code *never* sees any of the Controller classes and vice versa.

I've been doing this sort of scheme before Java even, in C++ way back when like 10 years ago.

Code is clean this way, and it works much better in a team setting.

We should create an article about MVC, and then emphasize how V should be 100% isolated from C both ways. This scheme is a complete winner.

Denis Robert replied on Thu, 2009/05/07 - 12:45pm

Wow!!!! What a load of ****.... Not defining a UI, and simply generating it from the model? That might be fine for an initial prototype, but real, business-oriented UI ***MUST*** be defined based on the user's WORKFLOW, not on the underlying model used by system developers to represent the domain. Sorry, you'll ALWAYS end up with a horrible, unuseable UI if you do what the author is recommending for a production UI. On the other hand, I'm all for generating UIs from the model to validate the assumptions in the model itself, during development. But to put that in front of end-user is idiotic, not to mention cruel to the poor end users who have to suffer their software developer's self-centeredness... Software is built for users, not programmers (unless the programmers themselves are the software's end users).

Mike P(Okidoky) replied on Thu, 2009/05/07 - 12:59pm

I got a little excited because I though this would create a nice MVC discussion. I was a little off topic, sorry about that.

But now I'm looking at this openxava thing, and got curious. The Model here are the DTO type classes it seems. This is not an MVC type thing. This is more of a DTO visualization engine. A dynamic DTO editor. Annotations provide meta data to the gui generation engine it seems. The examples show how the amount of stuff you have to put inside annotations can get out of hand.

Would it not be nicer if you could have a separate meta file, in which you can define a gui. And in an intuitive way so you have to describe as little as possible. When the DTO gets an extra field, perhaps the meta file doesn't have to list it at all, and gui automatically gets the extra element. The annotation could be used to identify what meta script to invoke...

Javier Paniza replied on Fri, 2009/05/08 - 3:25am in response to: Mike P(Okidoky)

Hi Mike,

I've taken MVC to far stricter levels

OpenXava is not a MVC framework, so it does not follow the MVC rules. 

OpenXava is a Business Component oriented framework, where the software artifacts are organized around business concepts. OpenXava takes the business component to the point that all info about the same business concept is in the same file (the jpa entity, or a XML for each component in previous versions), and not scattered in several layers. 

Business Component is more practical than MVC if you are doing changes in business data and logic frequently, and this is very comon in business application. For example, if you have to change the way an Invoice do some calculation, possibly you need to add some methos and properties to your domain model, some database columns, modify your user interface, maybe your hardcode controllers, business delegate classes, session beans, dto classe, ...  Oops!. With a business component approach you do the change in only one file, and you are ready to see the change in short time.

In fact, the developers of OX were working using strict MVC, and they were changing to this business component approach in order to improved their productivity, really in order to survive.

I'm not again MVC, but OpenXava is not MVC. 

Alastair Nel replied on Fri, 2009/05/08 - 3:40am

I think that this concept is a good idea, although OpenXava is not the first implementation. Have you seen Naked Objects (http://www.nakedobjects.org/home/no_for_java_intro.shtml ) which has been around for some time and has a quite a large installed application in use by the Irish Government by real end users?

Javier Paniza replied on Fri, 2009/05/08 - 3:54am

Hi Denis,

Not defining a UI, and simply generating it from the model? That might be fine for an initial prototype, but real, business-oriented UI ***MUST*** be defined based on the user's WORKFLOW

This is not true at all.

A lot of business application developed with OpenXava have been in production for years. The result is the same as if you develop the UI by hand, only that the hard work is automatic. Indeed, OpenXava allows you to develop any part of the user interface manually, but most OpenXava applications (and some of them are usually very big) have been developed completly using user automatic interface.

The key is that the application is not a mirror of the domain model (OpenXava does not follow the NakedObject pattern). You use controllers to give to the module your custom behaviour, you can refine the view in a very flexible ways, moreover you can customize the way the UI is generated.

OpenXava was created after the applications, not before. We first write the real life production applications, and we start to automatize some of the task for developing these applications, until (after several years) most of the task have been automated. So OpenXava was useful for creating real life custom application from its very first beginning.

The applications developed using OpenXava includes:

  • City cencus management.
  • Personnel and payroll management.
  • Inventory and wealth managament for spanish public sector.
  • Local police management.
  • File workflow managament for city hall.
  • Record of input and output document in a city hall.
  • Traffic fine managament.
  • Employment bureau managament for hospitals.
  • Elections management.
  • Cemetery management.
  • Risky animal record.
  • Social services.
  • Presence control.

You can see more here.

These application are commercial and close code, so I cannot publish them in internet. But, if you have real interest in OpenXava, and have doubts about if it is ready for real life applications, you can connact with me, and I can show you some demos of these products.

Claus Luethje replied on Fri, 2009/05/08 - 4:00am in response to: Javier Paniza

I think, this is not up to the task of big apps for big customers. No separation of concerns, hardcoded GUI specifica next to JPA, ... . This sends shivers down my spine.

In the past, layers gave a structure to applications and it worked every time a saw it. I can't see OpenXava changing that.

Just my 0.02$,


Javier Paniza replied on Fri, 2009/05/08 - 4:11am

Hi Mike,

The examples show how the amount of stuff you have to put inside annotations can get out of hand.

Yes, but all the stuff around the same business concept is in this point. For example, if you are seeing the property amount of Invoice, you know that all info about this property is there, in this moment, you do not need to navigate several scattered files.

This is a natural evolution:

  • With C++ we used Invoice.h and Invoice.cpp, and now in Java we only have Invoice.java.
  • With Hiberante we used Invoice.hbm.xml and Invoice.java, and now in JPA we only have Invoice.java.

If this "cluttering" is ugly for you, a solution is to have a IDE with the option to show/hide annotations by package.

Would it not be nicer if you could have a separate meta file

No. We are fleeing from separte meta files. We started with EJB in 1999, so we have some aversion to separate files. The Home, SessionBeans, DTOS, ejb-jar.xml, jaws.xml, jboss.xm, etc. You needed to touch a lot of separate meta files to do simple changes. Horror!. Indeed, some year after, xdoclet was a very popular tools, just because it did not use seperate metafile, but a rich class.

I don't want to come back.



Javier Paniza replied on Fri, 2009/05/08 - 4:19am

Hi alastairnel,

OpenXava is not the first implementation. Have you seen Naked Objects

I cited nakedobject and other frameworks in the article.

OpenXava first version is from 2001, though open source since 2004.

OpenXava is not the only model-driven GUI generator framework, but possibly it is the most popular, with more than 90.000 downloads. 


Javier Paniza replied on Fri, 2009/05/08 - 4:36am

Hi Claus,

this is not up to the task of big apps for big customers.

Of course, big customers have big budgets and can affort big teams of very skilled developers. If you have a lot of money you do not need OpenXava.

layers gave a structure to applications and it worked every time a saw it

OpenXava applications are structured, only that not by technologica layer, but by business concepts.

We can say that OpenXava is for user interface the same that JPA is for database access.

If you uses JPA you do not write a database access layer, rather db access is done automatically by JPA engine, and you only annotate (declarative) your domain class. In this way you work less, you need less developers, you need less time, moreover you can change from a database to another more easily than if you would write your "layer" by hand.

If you uses OpenXava you do not write a user interface layer, rather user interface is done automatically by OpenXava engine, and you only annotate (declarative) your domain class. In this way you work less, you need less developers, you need less time, moreover you can change from a user interface technology to another more easily than if you would write your "layer" by hand.

For example, OX3 was not AJAX, and OX3.1 supports AJAX. You only need to update your OX application to OX3.1 in order to convert you application to AJAX instantly, without touching a single line of code. Can you do it using your layers and handmade UIs?

Igor Laera replied on Fri, 2009/05/08 - 8:28am

I totally *LOVE* this concept. I always thought about modern GUI Systems as something you need to design extensively, waste alot of money on it, and 80% of it is either never used OR even appreciated. Later, when you release the application with +50 or 100 forms, you might sense: "Hey if I look at this bar or this menus or this entry forms: they QUITE look the same! If I only could find the "formula" to extract this data off the model/ metadata and apply it by some simple rules..." Some people tried this - and failed. You spend numerous days (or let people spend) on XAML or XUL, or "other" new ways to reduce complexity. But you simply can't. At the end you have 100 different .jsp pages or 100 different .guixml. You might get help by gui designers like JFormDesigner, Matisse, Jigloo. But look at the screenshots. It's like Adobe Illustrator or Corel Draw. The most people can't paint, draw or have even the remotest sense of usability. Without resources, they will always create something that look ugly - and unfortunately, half of the open source tools look *EXACTLY* like that. But why has it do be that way? I don't want to make "art"! I want a logical, functional, stable gui. On a certain Os and Window Environment, say KDE, 80% of the gui *should* look the same, with the same distance of the "Ok" button to the border, the same type of usability across all apps. When you simply had to change one annotation, one property to move an option "out" of a large sheet of "settings checkboxes" to an submenu which opens an popup and you can now change the content of that setting - and all other "checkboxes" simply move one up in the group without firing up that "gui photoshop" or touching 5 different files in 5 different packages... There is no doubt, modern IT has to become more industrial. Creating good looking, stable and functional "surfaces" to work on, we need definitely more automatisms and more magic. 10 years ago, nobody could believe, what you can do *today* with code and databases; how simple CRUD operations and webpages and database layers become. Still there are areas, if you try to think out of the box, you have 100 naysayers behind their photoshops saying "What? A database layer to map objects to rational tables? Impossible. Don't even think about it!"

ycs wyw replied on Fri, 2009/05/08 - 1:32pm


I also think this kind of tools are very useful, but I don't think the idea is completely incompatible with MVC. Maybe, the developer that follows MDD starts programming the domain model, and test/use the results immediately with this tools. But if the generated UI is not good enough (or needs additional domain business logic), the developer can continue programming the desired user interface, controller/s, business logic,... In this case, the developer probably will *reuse* the previous/tested domain model code (not only as JPA entities, but also as DTOs, and temporary data holders for UI and business logic).

I don't know much about OpenXava, but there are frameworks that allow the combination of automatic UI (for simple entities), with manual UI (for complex business logic/workflows), to achieve productivity without feature limitations. Does OpenXava allow this combination?

Thanks for the article.

P.D: maybe the list of similar products is small, and should be completed with references to dynamic pages like "wiki":

Manjuka Soysa replied on Sun, 2009/05/10 - 5:09am

Like some of the others commenting, I have also found generated forms to be never 100% what I want. I might want different layouts for different entities, inter-dependencies between components, custom components, etc. I have settled on having a framework with EJB3 (Hibernate), an extensible base DAO and some base classes for different types of searchers and forms.

The only entity-specific GUI class needed is a jpanel (to be contained in a form) and can be designed graphically (eg. with Matisse on Netbeans), with annotations for binding and validation cutting down the custom code. While you still end up with more code than OpenXava/NakedObjects-like frameworks, you get complete flexibility.

Javier Paniza replied on Mon, 2009/05/11 - 3:40am in response to: Manjuka Soysa

Hi Manjuka,

entity-specific GUI class needed is a jpanel ... While you still end up with more code than OpenXava/NakedObjects-like frameworks, you get complete flexibility.

Just mix in your application the two approach, and get the better of two worlds.

In the other hand, this article talks about user interface evolution. If you are using jpanel as base of your gui, how much will you cost to migrate your existing application to web, or to flex?



Javier Paniza replied on Mon, 2009/05/11 - 3:43am in response to: ycs wyw

there are frameworks that allow the combination of automatic UI (for simple entities), with manual UI (for complex business logic/workflows), to achieve productivity without feature limitations. Does OpenXava allow this combination?

Of course, look at the chapter 9 of reference guide. 

Jean-loup Comeliau replied on Wed, 2009/12/23 - 5:24am

Thanks for your article. To me, this is only confirmation that modeling (or defining) is more appropriate than pure coding for implementing durable and flexible business applications: that's in fact the main driver behind MDD, which is now a mature approach. I also think big customers with big budgets can strongly benefit from the abstraction and extensibility allowed by MDD principles.

There's one post saying that OpenXava does not enforce separation of concerns and I think that may be a relevant point since the model, the behaviors and the views all reside in the Java classes, which are typically only accessed by the programmer.

I have been successfully using LEONARDI for some years (see also www.lyria.com) and I am surprised there is no mention of it in this thread. LEONARDI is based on the same principle: no code generation, but GUI automation from the model executed by a runtime engine. However, with LEONARDI, the model (a set of xml files) is well seperated from the technology, which answers the issue of separating concerns and allows non programmers to implement, for the most part, their own, real-world business application. And I've experienced the same benefits as the ones described here: technology independence, extensibility, durability and ease of maintenance.

Douda Amirouche replied on Sat, 2010/03/27 - 2:34pm

Hi Javier and big thanks for your article, I just started to use OpenXava, I found it very important for business softwares, it is promising, good luck for the futur versions.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.