It has been announced that TIBCO has dropped the commercial support of General Interface (GI). Instead, it was advised to use some other well supported and maintained RIA framework. Well, Vaadin is a RIA framework, maintained and well supported. Let’s see how it compares to GI.
Architectural differences
The biggest difference between the frameworks is already visible by a quick look to their architectures. GI is purely a client side web framework which provides JavaScript libraries to build your web UI and communicate with a backend server. A usual case is that the backend is exposed as a webservice or other tools, like DWR, are used. On top of the libraries, GI provides its own IDE, also a GI application, to build your own web UI.
Vaadin has a different approach. It consists of server side UI components which you can use to build the application on server side. Each server side component has its counterpart on the browser. The communication between server and client side is handled by the framework itself so the developer can concentrate on application logic. This way you don’t have to expose your backend as a webservice. Anyway, if you already have some existing service you want to use, you can call it from the Vaadin UI server using Java and bind the data to UI components.
This difference has a huge implication to the work of an application developer. With General Interface, one should implement all the UI logic with JavaScript. With Vaadin, one uses Java to implement the logic. This makes it possible to use powerful Java IDEs for development. On top of that, the framework handles the communication between the browser and the server so that can be removed from the developers to-do list.
How to develop a basic app with Vaadin
The General Interface documentation has a tutorial app for creating a basic application to retrieve the city and state for a given zip code. A picture of the app is below. To implement a similar application with Vaadin, is a bit different.
First of all, you should have the development environment set up. Here are good instructions for it. Then you can get your hands dirty. A good starting point is to define the structure of the UI. What components it has and how to layout them. The same thing that you would do with the appCanvas.xml in GI. With Vaadin, this is done in Java code. Here’s an example of how you can build the area for the zip code field and button.
Label label = new Label("Type Zip Code");
TextField zipInput = new TextField();
Button button = new Button("Find City and State");
HorizontalLayout inputArea = new HorizontalLayout(label, zipInput, button);
The background color of the input area is grayish in the tutorial. The implementation with Vaadin is a bit different than with GI where you can add the CSS styles directly to the components using Properties Editor. The Vaadin approach is to add a style name to the component and use that to create CSS rules for components with the specified style name.
java:
inputArea.addStyleName("inputarea");
css:
.inputarea {
background-color: #e8e8f5;
}
After you have the components in place, you should implement the logic for the button click. In GI, you could write JavaScript code with Events Editor which is executed when the button is clicked. As was said, Vaadin is a server side framework so event handling works a bit differently. When the button is clicked on the browser, the framework will send an http request to the server with the information about the clicked button. Then on the server we execute the application logic code for the button click. This custom code can be specified by adding a click listener to the button.
button.addClickListener(new ClickListener() {
@Override
public void buttonClick(ClickEvent event) {
String zipCode = zipInput.getValue();
Address address = service.getAddressForZipCode(zipCode);
cityField.setValue(address.getCity());
stateField.setValue(address.getState());
}
});
It’s a good practice to not mess up your UI code with backend logic. So we have abstracted the logic to retrieve the state and city behind a service object. Note that the service class is not a part of Vaadin but it’s a class created for this project. Here you can also see how you map data to Vaadin components. That’s also purely Java so no need for XML mapping. In the example, we just set the values of the components but it’s recommended to use Vaadin Data Model. If you use that you don’t need to set the value every time it changes. Instead, you modify the value of a Property and it will notify all the UI components it has been binded to.
Check the project on GitHub to see how all this has been put together. Below is a picture of what the app looks like. You can also try it as live demo.
Disclaimer: the examples do not include all the required code to make the application look exactly like this. Please, check the UI code in GitHub to see it all.
From GI to Vaadin
So far, we looked at the main differences in application development with Vaadin and GI. Anyway, if you want to migrate from GI to Vaadin, you most likely want to do this step by step. Basically, there are two approaches. Either you embed a Vaadin UI to your existing application or you embed your existing GI application to Vaadin UI as a JavaScript component. The best suited approach depends heavily on the application so the choice is up to you.
To get more information about the Vaadin framework, please check Book of Vaadin. There is also an active forum to boost your development.