- Approaches to DDoS Protection: An Overview on Keeping Your Networks Protected
- Key Components Of Your Resiliency Strategy
- SaaS and E-Discovery: Navigating Complex Waters
- SaaS 2011: Adoption Soars, Yet Deployment Concerns Linger
- Solving Big Data Challenges with Simplicity & Speed
- Bring Salesforce.com Alive with Your Key Business Processes: Register Now
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
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 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.
WWebWidget, there is
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
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
WTreeNode uses this feature to implement client-side expand/collapse toggling.