Writing a Server-Side Web Application

Resources

A user interface can display images or have links to web pages or downloadable documents. These are handled as resources, which can be external or provided by the web server or the application itself. Section 4.4, “Images and Other Resources” gives a practical overview of the different types of resources.

Themes

The presentation and logic of the user interface are separated. While the UI logic is handled as Java code, the presentation is defined in themes as CSS or SCSS. Vaadin includes some built-in themes. User-defined themes can, in addition to style sheets, include HTML templates that define custom layouts and other theme resources, such as images. Themes are discussed in detail in Chapter 8, Themes, custom layouts in Section 6.14, “Custom Layouts”, and theme resources in Section 4.4.4, “Theme Resources”.

Data Binding

Field components are essentially views to data, represented in the Vaadin Data Model. Using the data model, the components can get their values from and update user input to the data model directly, without the need for any control code. A field component is always bound to a property and a group of fields to an item that holds the properties. Items can be collected in a container, which can act as a data source for some components such as tables or lists. While all the components have a default data model, they can be bound to a user-defined data source. For example, you can bind a Table component to an SQL query response. For a complete overview of data binding in Vaadin, please refer to Chapter 9, Binding Components to Data.

4.2. Building the UI

Vaadin user interfaces are built hierarchically from components, so that the leaf components are contained within layout components and other component containers. Building the hierarchy starts from the top (or bottom - whichever way you like to think about it), from the UI class of the application. You normally set a layout component as the content of the UI and fill it with other components.

public class MyHierarchicalUI extends UI { @Override

protected void init(VaadinRequest request) {

// The root of the component			hierarchy
VerticalLayout content	= new		VerticalLayout();
content.setSizeFull();	//	Use entire window
setContent(content);	//	Attach to the UI

//Add some component content.addComponent(new Label("Hello!"));

//Layout inside layout

HorizontalLayout hor = new HorizontalLayout(); hor.setSizeFull(); // Use all available space

// Couple of horizontally laid out components Tree tree = new Tree("My Tree",

TreeExample.createTreeContent());

hor.addComponent(tree);

Table table = new Table("My Table", TableExample.generateContent());

table.setSizeFull();

hor.addComponent(table); hor.setExpandRatio(table, 1); // Expand to fill

64	Building the UI

Writing a Server-Side Web Application

content.addComponent(hor); content.setExpandRatio(hor, 1); // Expand to fill

}

}

The component hierarchy could be illustrated with a tree as follows:

UI

`-- VerticalLayout

|-- Label

`-- HorizontalLayout

|-- Tree

`-- Table

The result is shown in Figure 4.2, “Simple Hierarchical UI”.

Figure 4.2. Simple Hierarchical UI

The built-in components are described in Chapter 5, User Interface Components and the layout components in Chapter 6, Managing Layout.

The example application described above just is, it does not do anything. User interaction is handled with event listeners, as described a bit later in Section 4.3, “Handling Events with Listeners”.

4.2.1. Application Architecture

Once your application grows beyond a dozen or so lines, which is usually quite soon, you need to start considering the application architecture more closely. You are free to use any object-ori- ented techniques available in Java to organize your code in methods, classes, packages, and libraries. An architecture defines how these modules communicate together and what sort of dependencies they have between them. It also defines the scope of the application. The scope of this book, however, only gives a possibility to mention some of the most common architectural patterns in Vaadin applications.

The subsequent sections describe some basic application patterns.The Section 11.14, “Accessing Session-Global Data” discusses the problem of passing essentially global references around, a common problem which is also visited in Section 4.2.5, “Accessing UI, Page, Session, and Service”.

Application Architecture

65

Writing a Server-Side Web Application

4.2.2. Compositing Components

User interfaces typically contain many user interface components in a layout hierarchy. Vaadin provides many layout components for laying contained components vertically, horizontally, in a grid, and in many other ways.You can extend layout components to create composite components.

class MyView extends VerticalLayout {

TextField	entry	= new TextField("Enter this");
Label	display	=	new Label("See this");
Button	click	=	new Button("Click This");

public MyView() { addComponent(entry); addComponent(display); addComponent(click);

// Configure it a bit setSizeFull(); addStyleName("myview");

}

}

// Use it

Layout myview = new MyView();

This composition pattern is especially supported for creating forms, as described in Section 9.4.3, “Binding Member Fields”.

While extending layouts is an easy way to make component composition, it is a good practice to encapsulate implementation details, such as the exact layout component used. Otherwise, the users of such a composite could begin to rely on such implementation details, which would make changes harder. For this purpose, Vaadin has a special CustomComponent wrapper, which hides the content representation.

class MyView extends CustomComponent {

TextField	entry	= new TextField("Enter this");
Label	display	= new Label("See this");
Button	click	=	new Button("Click This");
public MyView() {
Layout layout =			new VerticalLayout();

layout.addComponent(entry);

layout.addComponent(display);

layout.addComponent(click);

setCompositionRoot(layout);

setSizeFull();

}

}

// Use it

MyView myview = new MyView();

For a more detailed description of the CustomComponent, see Section 5.22, “Component Composition with CustomComponent”. The Vaadin Plugin for Eclipse also includes a visual editor for composite components, as described in Chapter 7, Visual User Interface Design with Eclipse.

66	Compositing Components

Writing a Server-Side Web Application

4.2.3. View Navigation

While the most simple applications have just a single view (or screen), perhaps most have many. Even in a single view, you often want to have sub-views, for example to display different content. Figure 4.3, “Navigation Between Views” illustrates a typical navigation between different top-level views of an application, and a main view with sub-views.

Figure 4.3. Navigation Between Views

The Navigator described in Section 11.9, “Navigating in an Application” is a view manager that provides a flexible way to navigate between views and sub-views, while managing the URI fragment in the page URL to allow bookmarking, linking, and going back in browser history.

Often Vaadin application views are part of something bigger. In such cases, you may need to integrate the Vaadin applications with the other website.You can use the embedding techniques described in Section 11.2, “Embedding UIs in Web Pages”.

4.2.4. Layered Architectures

Layered architectures, where each layer has a clearly distinct responsibility, are probably the most common architectures. Typically, applications follow at least a three-layer architecture:

•User interface (or presentation) layer

•Domain layer

•Data store layer

Such an architecture starts from a domain model, which defines the data model and the "business logic" of the application, typically as POJOs. A user interface is built on top of the domain model, in our context with the Vaadin Framework. The Vaadin user interface could be bound directly to the data model through the Vaadin Data Model, described in Chapter 9, Binding Components to Data. Beneath the domain model lies a data store, such as a relational database. The dependencies between the layers are restricted so that a higher layer may depend on a lower one, but never the other way around.

View Navigation

67