Programmers Quotes

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:

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

This article tries to demonstrate that Java can be more productive than Ruby. We are going to develop the same application of the article Rolling with Ruby on Rails Revisited (part 1 and part 2) but using POJOs annotated with JPA and a Model Driven Framework, OpenXava in this case. The result is that with less code, and less time you obtain a more powerful application.

Ruby and rails: The regressive framework

Ruby on rails is so elegant, so easy, so productive. I cannot avoid read and heard continuously these comments. For example, the article Rolling with Ruby on Rails Revisited of Bill Walton says:

“What would you think if I told you that you can develop a web application at least ten times faster with Rails than you can with a typical Java framework?”

Oops! Ten times faster!

Well, after these comments I decided to learn Ruby on Rails. I need to know the true key of the productivity and programmer happiness.

After have a taste of RnR I found it a very classic framework, with old techniques:

• Ruby is a dynamically typed language, as Smalltalk. I prefer statically typed languages.
• Scaffolding is passive code generation, as IDE wizards or AppFuse. I prefer active code generation, or even better, no code generation at all.
• Relational database centric: the code generators and ActiveRecord promote think first in tables after in classes. I prefer a more pure OO, as Hibernate, JPA or even ODBMS.
• MVC: I’m looking for something newer and better that an old MVC framework.

The Java problem: Java developers

The productivity in Java world is a cultural problem, not a technical one. That is this is not a Java fault, it’s our fault, we, the Java developers, need to design very beautiful architectures, to apply everywhere the GoF patterns, to do everything reusable, to put 3 tiers in all our systems and to use web services for all. We are not looking for simplicity, therefore we have not found it. But, Java is a very elegant language that allows simpler approach to software development.

Java productivity: The other way

A way for productivity is to use a Model Driven approach. That is, develop the model part, and only the model part, of our application, and to use a framework to produce all the application from it. MDA, OpenXava, Trails, NakedObjects, RomaFramework and JMatter are examples of this approach.

The goal

This is the main screen of the wanted application:

Basically, the app’s supposed to do three things:

• Display a list of all recipes.
• Create new recipes and edit existing recipes.
• Assign a recipe to a category (like “dessert” or “soup”).

The Ruby on Rails first sprint

The first step using RnR is creating the new project, from command line you have to write:

$ rails cookbook2

Now you must create and configure your database.

Then it’s the time for writing your first code, in this case SQL code:

Obviously you have to execute these sentences against your database.

And the final step is generate the Ruby code, you only need execute the next command in the shell of your O.S:

$ ruby script\generate scaffold recipe recipe

$ ruby script\generate scaffold category category

Yes. You have the very first version of your RnR application ready to run.

Yes, very little work, a simple “create table”, and executing a wizard. Let’s see the result.

The Rails result

This is the resulting application:

Little work. Little result.

The JPA on OX first sprint

Go on using OpenXava. The first step using OpenXava is creating the new project:

$ ant CreateNewProject.xml -Dproject=CookBook 

Now you must create and configure your database.

Then it’s the time for writing your first code, in this case Java code:

Recipe.java:

Category.java:

And the final step is to generate the dababase schema, you only need to execute the next ant target from your project:

$ ant updateSchema

Yes. You have the very first version of your OpenXava application ready to run.

Yes, very little work, a simple POJOs, and executing ‘updateSchema’. Let’s see the result.

The OpenXava result

This is the resulting application:

Note that the user can create,update, delete, generate PDF from list, export the list to excel, order by each column, paging with support for large resultsets and filter data. Moreover you can deploy directly, with no code, only executing an ant target, your application in a JSR-168 portal, and the look & feel of the OpenXava portlet adapts to the look & feel of the portal.

This is, from first time, an application ready for production.

Little work, polished result.

From a philosophical point of view the difference here between RnR and OX is that in RnR you write first the tables and in OpenXava you write first the classes.

The controllers

Rails has generated for you the controller logic for the basic CRUD, you can see it here:

In the other hand OX has not generated any code for CRUD, OpenXava just have a generic code for doing CRUD and Printing, and it is assigned automatically to all entities. You can write your own generic CRUD logic, or you can write a specific logic for a particular entity, but you haven’t a controller code for each entity. In this way, you have less code to maintain, and you can change the logic of all CRUD modules touching in a single place.

That is for controllers Rails uses generated code while OX uses generic code.

You can learn more about OX controllers in OpenXava wiki.

Adding a relationship

For adding a relationship from category to recipe in Ruby you have to write the next code in category.rb:

and this one in recipe.rb:

Yes, pretty simple. But, you have more work to do. You must edit cookbook2\app\views\recipe\_form.rhtml and add the next code:

The result is:

For its part, in OpenXava you have to define the relationship using JPA in Category.java:

and in Recipe.java:

And you do not need to touch any HTML-like code. You application will show just this:

You have a link for modifying or creating new categories from here.

Without adding any additional code if the user go to the Category module he will obtain a collection of Recipes in each Category, as following:

In this point the RnR application still does not have this features, you need to write some Ruby and HTML to code to obtain the same effect.

The main difference here between RnR and OX here is that in OX you do not write any HTML-like code, indeed you do not write User Interface code at all.

Calculating a initial value

The next step in the Ruby on Rails tutorial is to generated a initial value for a property. In RnR you have to edit the controller code in order to achieve it. Let’s see it:

You modify the new and update method adding the line:

The equivalent in OX is adding the @DefaultValueCalculator annotation in model:

You obtain the same effect in a more declarative way.

That, while in RnR you put the code on controller, in OX the code for calculating initial values, for validations and for business logic in general is on the model. OX promotes moving business logic from controller to model.

As curiosity, in the RnR article says: “I modified the model files so I need to restart our web server.” While using Eclipse WTP I only need to press Ctrl – B, and click on refresh in my browser in order to see the change of my model in my OpenXava application.

Conclusion

The main difference between Ruby on Rails and OpenXava is that RnR is a MVC framework, you have to write the model, the view and the controllers, and OX is a model-driven framework, you only need to write the model. The result is less code for a better application.

Another big difference is that RnR uses passive code generation; that is, it generates the code for you, but after it if you want to extend or refine the code you have to edit the generated code. OpenXava does not use code generation, the only code you have is the code you write.

You can find productivity inside the Java universe.

References

To learn more:

• OpenXava site
• Article Rolling with Ruby on Rails Revisited (part 1 and part 2)
• Other model-driven frameworks: Trails, NakedObjects, RomaFramework and JMatter