User Interface Components

// Clicking the button creates and runs a work thread button.addListener(new Button.ClickListener() {

public void buttonClick(ClickEvent event) { final WorkThread thread = new WorkThread(); thread.start();

// The button hides until the work is done. button.setVisible(false);

}

});

Figure 5.61. Starting Heavy Work

5.21. Slider

The Slider is a vertical or horizontal bar that allows setting a numeric value within a defined range by dragging a bar handle with the mouse. The value is shown when dragging the handle.

Slider has a number of different constructors that take a combination of the caption, minimum and maximum value, resolution, and the orientation of the slider.

// Create a vertical slider

final Slider vertslider = new Slider(1, 100); vertslider.setOrientation(SliderOrientation.VERTICAL);

Slider Properties

min

Minimum value of the slider range. The default is 0.0.

max

Maximum value of the slider range. The default is 100.0.

resolution

The number of digits after the decimal point. The default is 0.

orientation

The orientation can be either horizontal (SliderOrientation.HORIZONTAL) or vertical (SliderOrientation.VERTICAL). The default is horizontal.

As the Slider is a field component, you can handle value changes with a ValueChangeListener. The value of the Slider field is a Double object.

//Shows the value of the vertical slider final Label vertvalue = new Label(); vertvalue.setSizeUndefined();

//Handle changes in slider value. vertslider.addValueChangeListener(

new Property.ValueChangeListener() {

public void valueChange(ValueChangeEvent event) { double value = (Double) vertslider.getValue();

// Use the value

box.setHeight((float) value, Sizeable.UNITS_PERCENTAGE); vertvalue.setValue(String.valueOf(value));

User Interface Components

}

});

//The slider has to be immediate to send the changes

//immediately after the user drags the handle. vertslider.setImmediate(true);

You can set the value with the setValue() method defined in Slider that takes the value as a native double value. The setter can throw a ValueOutOfBoundsException, which you must handle.

//Set the initial value. This has to be set after the

//listener is added if we want the listener to handle

//also this value change.

try { vertslider.setValue(50.0);

} catch (ValueOutOfBoundsException e) {

}

Alternatively, you can use the regular setValue(Object), which does not do bounds checking.

Figure 5.62, “The Slider Component” shows both vertical (from the code examples) and horizontal sliders that control the size of a box. The slider values are displayed also in separate labels.

Figure 5.62. The Slider Component

CSS Style Rules

.v-slider {}

.v-slider-base {}

.v-slider-handle {}

The enclosing style for the Slider is v-slider. The slider bar has style v-slider-base. Even though the handle is higher (for horizontal slider) or wider (for vertical slider) than the bar, the handle element is nevertheless contained within the slider bar element. The appearance of the handle comes from a background image defined in the background CSS property.

User Interface Components

5.22. Component Composition with CustomComponent

The ease of making new user interface components is one of the core features of Vaadin.Typically, you simply combine existing built-in components to produce composite components. In many applications, such composite components make up the majority of the user interface.

To create a composite component, you need to inherit the CustomComponent and call the setCompositionRoot() in the constructor to set the composition root component. The root component is typically a layout component that contains multiple components.

For example:

class MyComposite extends CustomComponent { public MyComposite(String message) {

//A layout structure used for composition Panel panel = new Panel("My Custom Component"); panel.setContent(new VerticalLayout());

//Compose from multiple components

Label label = new Label(message); label.setSizeUndefined(); // Shrink panel.addComponent(label); panel.addComponent(new Button("Ok"));

//Set the size as undefined at all levels panel.getContent().setSizeUndefined(); panel.setSizeUndefined(); setSizeUndefined();

//The composition root MUST be set setCompositionRoot(panel);

}

}

Take note of the sizing when trying to make a customcomponent that shrinks to fit the contained components. You have to set the size as undefined at all levels; the sizing of the composite component and the composition root are separate.

You can use the component as follows:

MyComposite mycomposite = new MyComposite("Hello");

The rendered component is shown in Figure 5.63, “A Custom Composite Component”.

Figure 5.63. A Custom Composite Component

You can also inherit any other components, such as layouts, to attain similar composition. Even further, you can create entirely new low-level components, by integrating pure client-side components or by extending the client-side functionality of built-in components. Development of new components is covered in Chapter 16, Integrating with the Server-Side.

User Interface Components

5.23. Composite Fields with CustomField

The CustomField is a way to create composite components like with CustomComponent, except that it implements the Field interface and inherit AbstractField, described in Section 5.2.3, “Field Components (Field and AbstractField)”. A field allows editing a property value in the Vaadin data model, and can be bound to data with field groups, as described in Section 9.4, “Creating Forms by Binding Fields to Items”. The field values are buffered and can be validated with validators.

A composite field class must implement the getType() and initContent() methods. The latter should return the content composite of the field. It is typically a layout component, but can be any component.

It is also possible to override validate(), setInternalValue(), commit(), setPropertyDataSource, isEmpty() and other methods to implement different functionalities in the field. Methods overriding setInternalValue() should call the superclass method.

Chapter 6

Managing Layout

Ever since the ancient xeroxians invented graphical user interfaces, programmers have wanted to make GUI programming ever easier for themselves. Solutions started simple. When GUIs appeared on PC desktops, practically all screens were of the VGA type and fixed into 640x480 size. Mac or X Window System on UNIX were not much different. Everyone was so happy with such awesome graphics resolutions that they never thought that an application would have to work on a radically different screen size. At worst, screens could only grow, they thought, giving more space for more windows. In the 80s, the idea of having a computer screen in your pocket was simply not realistic. Hence, the GUI APIs allowed placing UI components using screen coordinates. Visual Basic and some other systems provided an easy way for the designer to drag and drop components on a fixed-sized window. One would have thought that at least translators would have complained about the awkwardness of such a solution, but apparently they were not,

Managing Layout

as non-engineers, heard or at least cared about. At best, engineers could throw at them a resource editor that would allow them to resize the UI components by hand. Such was the spirit back then.

After the web was born, layout design was doomed to change for ever. At first, layout didn't matter much, as everyone was happy with plain headings, paragraphs, and a few hyperlinks here and there. Designers of HTML wanted the pages to run on any screen size. The screen size was actually not pixels but rows and columns of characters, as the baby web was really just hypertext, not graphics.That was soon to be changed.The first GUI-based browser, NCSA Mosaic, launched a revolution that culminated in Netscape Navigator. Suddenly, people who had previously been doing advertisement brochures started writing HTML. This meant that layout design had to be easy not just for programmers, but also allow the graphics designer to do his or her job without having to know a thing about programming. The W3C committee designing web standards came up with the CSS (Cascading Style Sheet) specification, which allowed trivial separation of appearance from content. Later versions of HTML followed, XHTML appeared, as did countless other standards.

Page description and markup languages are a wonderful solution for static presentations, such as books and most web pages. Real applications, however, need to have more control. They need to be able to change the state of user interface components and even their layout on the run. This creates a need to separate the presentation from content on exactly the right level.

Thanks to the attack of graphics designers, desktop applications were, when it comes to appearance, far behind web design. Sun Microsystems had come in 1995 with a new programming language, Java, for writing cross-platform desktop applications. Java's original graphical user interface toolkit, AWT (Abstract Windowing Toolkit), was designed to work on multiple operating systems as well as embedded in web browsers. One of the special aspects of AWT was the layout manager, which allowed user interface components to be flexible, growing and shrinking as needed. This made it possible for the user to resize the windows of an application flexibly and also served the needs of localization, as text strings were not limited to some fixed size in pixels. It became even possible to resize the pixel size of fonts, and the rest of the layout adapted to the new size.

Layout management of Vaadin is a direct successor of the web-based concept for separation of content and appearance and of the Java AWT solution for binding the layout and user interface components into objects in programs. Vaadin layout components allow you to position your UI components on the screen in a hierarchical fashion, much like in conventional Java UI toolkits such as AWT, Swing, or SWT. In addition, you can approach the layout from the direction of the web with the CustomLayout component, which you can use to write your layout as a template in XHTML that provides locations of any contained components.

The moral of the story is that, because Vaadin is intended for web applications, appearance is of high importance. The solutions have to be the best of both worlds and satisfy artists of both kind: code and graphics. On the API side, the layout is controlled by UI components, particularly the layout components. On the visual side, it is controlled by themes. Themes can contain any HTML, CSS, and JavaScript that you or your web artists create to make people feel good about your software.

Because of pressing release schedules to get this edition to your hands, we were unable to completely update this chapter. The content is up-to-date with Vaadin 7 to a large extent, but some topics require revision. Please consult the web version once it is updated, or the next print edition.

172