Architecture

Figure 3.2. Java Web Applications and Servlets

Web applications are usually packaged and deployed to a server as WAR (Web application ARchive) files, which are Java JAR packages, which in turn are ZIP compressed packages. The web application is defined in a WEB-INF/web.xml deployment descriptor, which defines the servlet classes and also the mappings from request URL paths to the servlets. This is described in more detail in Section 4.8.3, “Deployment Descriptor web.xml”.The class path for the servlets and their dependencies includes the WEB-INF/classes and WEB-INF/lib folders. The WEB-INF is a special hidden folder that can not be accessed by its URL path.

The servlets are Java classes that handle HTTP requests passed to them by the server through the Java Servlet API. They can generate HTML or other content as a response. JSP pages, on the other hand, are HTML pages, which allow including Java source code embedded in the pages. They are actually translated to Java source files by the container and then compiled to servlets.

The UIs of server-side Vaadin applications run as servlets. They are wrapped inside a VaadinServlet servlet class, which handles session tracking and other tasks. On the initial request, it returns an HTML loader page and then mostly JSON responses to synchronize the widgets and their server-side counterparts. It also serves various resources, such as themes. The server-side UIs are implemented as classes extending the UI class, as described in Chapter 4, Writing a Server-Side Web Application. The class is given as a parameter to the Vaadin Servlet in the web.xml deployment descriptor.

The Vaadin Client-Side Engine as well as client-side Vaadin applications are loaded to the browser as static JavaScript files. The client-side engine, or widget set in technical terms, needs to be located under the VAADIN/widgetsets path in the web application. The precompiled default widget set is served from the vaadin-client-compiled JAR by the Vaadin Servlet.

3.3. Client-Side Engine

The user interface of a server-side Vaadin application is rendered in the browser by the Vaadin Client-Side Engine. It is loaded in the browser when the page with the Vaadin UI is opened. The server-side UI components are rendered using widgets (as they are called in Google Web Toolkit) on the client-side. The client-side engine is illustrated in Figure 3.3, “Vaadin Client-Side Engine”.

56	Client-Side Engine

Architecture

Figure 3.3. Vaadin Client-Side Engine

The client-side framework includes two kinds of built-in widgets: GWT widgets and Vaadin-spe- cific widgets. The two widget collections have significant overlap, where the Vaadin widgets provide a bit different features than the GWT widgets. In addition, many add-on widgets and their server-side counterparts exist, and you can easily download and install them, as described in Chapter 17, Using Vaadin Add-ons. You can also develop your own widgets, as described in Chapter 13, Client-Side Vaadin Development.

The rendering with widgets, as well as the communication to the server-side, is handled in the ApplicationConnection. Connecting the widgets with their server-side counterparts is done in connectors, and there is one for each widget that has a server-side counterpart. The framework handles serialization of component state transparently, and includes an RPC mechanism between the two sides. Integration of widgets with their server-side counterpart components is described in Chapter 16, Integrating with the Server-Side.

3.4. Events and Listeners

Vaadin offers an event-driven programming model for handling user interaction. When a user does something in the user interface, such as clicks a button or selects an item, the application needs to know about it. Many Java-based user interface frameworks follow the Event-Listener pattern (also known as the Observer design pattern) to communicate user input to the application logic. So does Vaadin.The design pattern involves two kinds of elements: an object that generates ("fires" or "emits") events and a number of listeners that listen for the events. When such an event occurs, the object sends a notification about it to all the listeners. In a typical case, there is only one listener.

Events can serve many kinds of purposes. In Vaadin, the usual purpose of events is handling user interaction in a user interface. Session management can require special events, such as time-out, in which case the event would actually be the lack of user interaction. Time-out is a special case of timed or scheduled events, where an event occurs at a specific date and time or when a set time has passed.

Events and Listeners

57

Architecture

To receive events of a particular type, an application must register a listener object with the event source. The listeners are registered in the components with an add*Listener() method (with a method name specific to the listener).

Most components that have related events define their own event class and the corresponding listener class. For example, the Button has Button.ClickEvent events, which can be listened to through the Button.ClickListener interface.

In the following, we handle button clicks with a listener implemented as an anonymous class:

final Button button = new Button("Push it!");

button.addClickListener(new Button.ClickListener() { public void buttonClick(ClickEvent event) { button.setCaption("You pushed it!");

}

});

Figure 3.4, “Class Diagram of a Button Click Listener” illustrates the case where an applicationspecific class inherits the Button.ClickListener interface to be able to listen for button click events. The application must instantiate the listener class and register it with addClickListener(). It can be an anonymous class, such as the one above. When an event occurs, an event object is instantiated, in this case a Button.ClickEvent.The event object knows the related UI component, in this case the Button.

Figure 3.4. Class Diagram of a Button Click Listener

In the ancient times of C programming, callback functions filled largely the same need as listeners do now. In object-oriented languages, we usually only have classes and methods, not functions, so the application has to give a class interface instead of a callback function pointer to the framework.

Section 4.3, “Handling Events with Listeners” goes into details of handling events in practice.

58	Events and Listeners