Library Overview

A Wt session starts when users access the application URL, and ends when users quit the application explicitly, or implicitly by leaving the webpage. To programmers, session management is transparent and similar to other GUI applications on multiuser systems. In its most naïve configuration, for every new Wt session, a process is spawned and used for the duration of the session. A server with N sessions (logged-in users, for instance), shall therefore have N processes running. Wt can be configured to use cookies or URL rewriting to bind requests to the correct session. With this architecture, all sessions run in their own memory space (a crash of one process can never influence other processes), and sessions cannot communicate with each other unless explicit communication mechanisms are used, providing an additional security safeguard. Because this model is notappropriate or even desired for public web applications, Wt may also be configured to multiplex all sessions onto a limited number or even only one process. This saves server resources and is more resilient to Denial-of-Service attacks. These deployment choices offered by Wt do not affect your program code, but are implemented at linktime or runtime.

Wt Widgets: Interaction with Browsers

Figure 2 illustrates Wt's widget hierarchy. At the top, WWidget exposes methods for organizing the layout and look of each widget. Both the layout and visual aspects are defined in terms of CSS. A drawback is that the layout model of CSS was designed for the markup of documents, and therefore not always intuitive for designing UIs.

Wt's core widgets, which map directly onto HTML building blocks, all inherit from WWebWidget. WWebWidget implementations specify how to render widget changes in terms of the HTML Document Object Model (DOM), and expose all capabilities of these HTML elements. For example, HTML buttons are represented by class WPushButton, HTML text becomes WText, and HTML tables become class WTable. Properties of the HTML blocks (attributes and content) are turned into methods of the classes, named consistently throughout the library. Widgets whose corresponding HTML element supports interaction with the keyboard or mouse, are descendants of WInteractWidget, which exposes these events as Wt::Signal<Event> objects. Form control widgets that may receive keyboard focus and can be enabled/disabled are descendants of WFormWidget, and expose additional events. The library propagates information in two directions between the browser DOM and the server-side widget tree: When the server-side application modifies a widget attribute (color change, enable/disable, or modification of the widget tree), this change is rendered in the web browser (through AJAX, if available). In the other direction, any change or event initiated by users on the DOM is automatically reflected in the widget (such as changes to the edited text of an HTML text input field, which corresponds to a WLineEdit widget). Events are propagated using a signal/slot mechanism (which is a particular implementation of the Observer pattern). This is both for events initiated by user action, such as text changes, mouse clicks, or focus changes, as well as events initiated by application code.

Figure 2: Wt's widget hierarchy.

Next to WWebWidget, there is WCompositeWidget. While WWebWidgets expose as much as possible all capabilities available in their browser-side implementations, WCompositeWidgets implement advanced widget functionality whose implementation details are completely encapsulated. For example, WTreeNode, which defines a node in a tree hierarchy, is internally implemented using WImage and WText widgets laid out in a 2×2 WTable. This internal organization is not exposed by inheriting from WCompositeWidget, and can thus be changed at any point in the future.

The look and organization of a new WCompositeWidget is specified by composition of existing widgets (which may be either WWebWidget or WCompositeWidgets), while the behavior is defined by connecting slots to various signals exposed by these widgets. New widgets are not limited to server-side event handling only, but can use the dynamic C++-to-JavaScript translation feature to bypass the server roundtrip for rendering visual updates (more on this later). For example, the WTreeNode uses this feature to implement client-side expand/collapse toggling.