<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<title>Wt: Library overview</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
$(document).ready(function() { searchBox.OnSelectItem(0); });
</script>
</head>
<body>
<div id="top"><!-- do not remove this div! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Wt
 <span id="projectnumber">3.2.3</span>
</div>
</td>
</tr>
</tbody>
</table>
</div>
<!-- Generated by Doxygen 1.7.5.1 -->
<script type="text/javascript">
var searchBox = new SearchBox("searchBox", "search",false,'Search');
</script>
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="index.html"><span>Main Page</span></a></li>
<li class="current"><a href="pages.html"><span>Related Pages</span></a></li>
<li><a href="modules.html"><span>Modules</span></a></li>
<li><a href="namespaces.html"><span>Namespaces</span></a></li>
<li><a href="annotated.html"><span>Classes</span></a></li>
<li><a href="files.html"><span>Files</span></a></li>
<li>
<div id="MSearchBox" class="MSearchBoxInactive">
<span class="left">
<img id="MSearchSelect" src="search/mag_sel.png"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
alt=""/>
<input type="text" id="MSearchField" value="Search" accesskey="S"
onfocus="searchBox.OnSearchFieldFocus(true)"
onblur="searchBox.OnSearchFieldFocus(false)"
onkeyup="searchBox.OnSearchFieldChange(event)"/>
</span><span class="right">
<a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
</span>
</div>
</li>
</ul>
</div>
</div>
<div class="header">
<div class="headertitle">
<div class="title">Library overview </div> </div>
</div>
<div class="contents">
<div class="textblock"><h2><a class="anchor" id="contents"></a>
Contents</h2>
<div style="margin-left: 10px; margin-bottom: 5px;"> <a class="el" href="overview.html#wwidget_sec"> 1. Widgets</a> </p>
<div style="margin-left: 10px; margin-bottom: 7px;"> <a class="el" href="overview.html#layout">1.1 Layout</a> <br/>
<a class="el" href="overview.html#style">1.2 Style</a> <br/>
<a class="el" href="overview.html#containers">1.3 Widget containers</a> <br/>
</div><p> <a class="el" href="overview.html#urls_sec"> 2. Application URL(s)</a> <br/>
</p>
<div style="margin-left: 10px; margin-bottom: 7px;"></div><p> <a class="el" href="overview.html#application_sec"> 3. Startup and session management</a> <br/>
</p>
<div style="margin-left: 10px; margin-bottom: 7px;"></div><p> <a class="el" href="overview.html#signal_slot"> 4. Signal/slot event handling</a> <br/>
</p>
<div style="margin-left: 10px; margin-bottom: 7px;"></div><p> <a class="el" href="overview.html#eventhandling"> 5. Optimizing client-side event handling</a> <br/>
</p>
<div style="margin-left: 10px; margin-bottom: 7px;"></div><p> <a class="el" href="overview.html#bootstrap"> 6. Application bootstrap</a> <br/>
</p>
<div style="margin-left: 10px; margin-bottom: 7px;"> <a class="el" href="overview.html#default_bootstrap">6.1 Default bootstrap</a> <br/>
<a class="el" href="overview.html#progressive_bootstrap">6.1 Progressive bootstrap</a> <br/>
</div><p> <a class="el" href="overview.html#sec_painting"> 7. Painting</a> <br/>
</p>
<div style="margin-left: 10px; margin-bottom: 7px;"></div><p> <a class="el" href="overview.html#internationalization_sec"> 8. Internationalization</a> <br/>
</p>
<div style="margin-left: 10px; margin-bottom: 7px;"></div><p> <a class="el" href="overview.html#deployment"> 9. Deployment</a> <br/>
</p>
<div style="margin-left: 10px; margin-bottom: 7px;"> <a class="el" href="overview.html#fastcgi">9.1 FastCGI</a> <br/>
<a class="el" href="overview.html#wthttpd">9.2 Built-in httpd</a> <br/>
<a class="el" href="overview.html#wtisapi">9.3 ISAPI</a> <br/>
</div><p> <a class="el" href="overview.html#configuration_sec"> 10. Configuration</a> </p>
<div style="margin-left: 10px; margin-bottom: 7px;"> <a class="el" href="overview.html#config_session">10.1 Session management (wt_config.xml)</a> <br/>
<a class="el" href="overview.html#config_general">10.2 General application settings (wt_config.xml)</a> <br/>
<a class="el" href="overview.html#config_fastcgi">10.3 FastCGI options (wt_config.xml)</a> <br/>
<a class="el" href="overview.html#config_wthttpd">10.4 Wt httpd (command-line or configuration file) options</a> <br/>
<a class="el" href="overview.html#config_isapi">10.5 ISAPI options (wt_config.xml)</a> <br/>
</div> <div style="margin-left: 10px; margin-bottom: 7px;"></div><p> <a class="el" href="overview.html#error_sec"> 11. Error-handling and logging</a> </div><h2><a class="anchor" id="wwidget_sec"></a>
1. Widgets</h2>
<p>The <a class="el" href="classWt_1_1WWidget.html" title="The abstract base class for a user-interface component.">WWidget</a> class represents a widget, which provides an abstraction of a visual entity. The entire user-interface is specified by creating a hierarchical structure of WWidgets, rooted at <a class="el" href="classWt_1_1WApplication.html#a17e118a04d962459484a12989a80bc05" title="Returns the root container.">WApplication::root()</a>. By reacting to events related to these widgets, you can perform business logic, and manipulate the widget hierarchy to update the user interface.</p>
<p>When inserting a widget in the widget hierarchy, ownership is transferred to its parent in the tree. Thus, when deleting a widget, all of its children are deleted as well, significantly reducing the burden of memory management related to widgets. When the <a class="el" href="classWt_1_1WApplication.html" title="Represents an application instance for a single session.">WApplication</a> object is deleted, the root of the tree is deleted, and in this way all resources associated with any widget are free'd.</p>
<p>Any descendent class of <a class="el" href="classWt_1_1WWidget.html" title="The abstract base class for a user-interface component.">WWidget</a> is a self-contained (reusable) class that encapsulates both the look and behaviour, enabling the design of the user interface in an orthogonal way.</p>
<h3><a class="anchor" id="layout"></a>
1.1 Layout</h3>
<p>Widgets are layed out (with a few exceptions) following this hierarchical structure. You have two choices for lay-out of children within a container.</p>
<ul>
<li>Either you use a CSS based layout (perhaps in combination with a <a class="el" href="classWt_1_1WTemplate.html" title="A widget that renders an XHTML template.">WTemplate</a> for the HTML markup), in which case the CSS style properties of the container and children together determine the result: each child manages its layout with respect to its sibling following a (rather complex) set of rules.</li>
</ul>
<ul>
<li>Alternatively, Wt provides <a class="el" href="classWt_1_1WLayout.html">layout managers</a> that may be used for layout, and this is especially useful for scenarios when CSS is not adequate</li>
</ul>
<p>CSS distinguishes between inline and block level elements (widgets) for deciding how to add them to the layout. Text-like widgets (<a class="el" href="classWt_1_1WWidget.html#ac78e3af143883334c82031790c87416e">inline</a>) flow with sibling inline widgets in lines, wrapping at the right edge of the parent container. In contrast, widgets displayed as a <a class="el" href="classWt_1_1WWidget.html#ac78e3af143883334c82031790c87416e">block </a> stack vertically with respect to sibling widgets. Block widgets allow more control over their position and size than inline widgets, and may also float to the left or right border of the parent container.</p>
<p>Layout managers are implemented by classes that derive from <a class="el" href="classWt_1_1WLayout.html" title="An abstract base class for layout managers.">WLayout</a>, and are used in conjunction with the <a class="el" href="classWt_1_1WContainerWidget.html" title="A widget that holds and manages child widgets.">WContainerWidget</a> container. A layout manager adapts the size and location of the children to the width and height of the parent. If you want the opposite (i.e. to adapt the size (width and/or height) of the parent to the size of the children, then you can still use layout managers, but you need to set additional alignment flags which determines how the layout is positioned in the parent in case of excess width and/or height.</p>
<h3><a class="anchor" id="style"></a>
1.2 Style</h3>
<p>For visual markup of widgets, the recommended way is to use CSS style sheets. These allow the visual look to be defined seperately from the the rest of the application. External stylesheets may be loaded using <a class="el" href="classWt_1_1WApplication.html#af377d541443b4bcea5fcc40be7c70173" title="Adds an external style sheet.">WApplication::useStyleSheet()</a>, and the internal stylesheet may be manipulated using <a class="el" href="classWt_1_1WApplication.html#a6a9a20d65ce9e7c2f62b27387c94e10d" title="Returns a reference to the inline style sheet.">WApplication::styleSheet()</a>.</p>
<p>In the stylesheets, you describe rules that are prefixed by CSS selectors. By setting matching style classes for your widgets using <a class="el" href="classWt_1_1WWidget.html#a4be23ecf48d5968efb5d926e38e01708" title="Sets (one or more) CSS style classes.">WWidget::setStyleClass()</a>, these rules will be applied to your widgets. The recommended way for visual response to events is by changing the style class for the widget.</p>
<p>In addition to style sheets, Wt also supports the direct manipulation of a widget's style, using <a class="el" href="classWt_1_1WWidget.html#ac1833c7c01599b3733712ab0bf3c3a0a" title="Returns the decoration style of this widget.">WWidget::decorationStyle()</a>.</p>
<h3><a class="anchor" id="containers"></a>
1.3 Widget containers</h3>
<p>With a few exceptions, all widgets are child of (and contained in) a container widget such as <a class="el" href="classWt_1_1WContainerWidget.html" title="A widget that holds and manages child widgets.">WContainerWidget</a> or <a class="el" href="classWt_1_1WTableCell.html" title="A container widget that represents a cell in a table.">WTableCell</a>. A widget may be inserted into a <a class="el" href="classWt_1_1WContainerWidget.html" title="A widget that holds and manages child widgets.">WContainerWidget</a> by adding the widget to the container using <a class="el" href="classWt_1_1WContainerWidget.html#a2cfe66d9b62940f889e99538a9f478d2" title="Adds a child widget to this container.">WContainerWidget::addWidget()</a>, or by passing the parent container as an argument to its constructor. You may also add a widget to a container using a layout manager.</p>
<h2><a class="anchor" id="urls_sec"></a>
2. Application URL(s)</h2>
<p>A Wt application, like any other CGI application, is deployed at a single location (URL) within your web server. In this mode, a Wt application is a single page web application: the URL does not change. Still, an application may manage multiple URLs that correspond to internal paths. These are URLs that are created by appending an internal path to the application URL. The internal path may be manipulated through <a class="el" href="classWt_1_1WApplication.html#a2c1a10aadc0d7ed877b5715b42ca4911" title="Changes the internal path.">WApplication::setInternalPath()</a>. When the internal path changes, this is reflected in the browser URL and an entry is added to the browser history, allowing the user to use the back and forward buttons to navigate through your application.</p>
<p>To avoid rerendering the entire widget tree for each internal path change, when Ajax is available, the internal path is indicated either by manipulating the URL using the HTML5 History API, or by using a name anchor (#) after the deployment URL. For a plain HTML session, the session ID is appended to the URL to avoid the session from reloading when the user navigates using a <a class="el" href="classWt_1_1WAnchor.html" title="A widget that represents an HTML anchor (to link to other documents).">WAnchor</a> to a new internal URL.</p>
<p>To effectively change the internal path and obtain consistent behaviour with or without JavaScript, you should use a <a class="el" href="classWt_1_1WAnchor.html" title="A widget that represents an HTML anchor (to link to other documents).">WAnchor</a> to let the user navigate to a new internal path. The easiest way to do this is by using the <a class="el" href="classWt_1_1WAnchor.html#ae3ea26646f135bf133871564f5d6798d" title="Sets a link to an internal path (deprecated).">WAnchor::setRefInternalPath()</a>. This refers the <a class="el" href="classWt_1_1WAnchor.html" title="A widget that represents an HTML anchor (to link to other documents).">WAnchor</a> to a URL generated by <a class="el" href="classWt_1_1WApplication.html#a37b4cf44f393688785ed3b34f53fead1" title="Returns a bookmarkable URL for the current internal path.">WApplication::bookmarkUrl()</a> for the new internal path (handling the plain HTML case), and binds a JavaScript slot to its <a class="el" href="classWt_1_1WInteractWidget.html#ae11e050cce0d4a8f742afa3ef92bfe8c" title="Event signal emitted when a mouse key was clicked on this widget.">WAnchor::clicked()</a> signal, which changes the internal path (handling the Ajax case).</p>
<p>Finally, you can listen for path changes using the <a class="el" href="classWt_1_1WApplication.html#a674fd6a2522d66d07908e8f3d82424a9" title="Signal which indicates that the user changes the internal path.">WApplication::internalPathChanged()</a> event to react to the user navigating through his history.</p>
<h2><a class="anchor" id="application_sec"></a>
3. Startup and session management</h2>
<p>In your application, e.g. from within your main(), you should <a class="el" href="classWt_1_1WServer.html#abca6890dab44d87bd3af64705ac072d3" title="Runs the Wt application server.">WRun()</a> to start the Wt application server. This method will return only when shutdown is signaled by the environment, and after the application server (and all remaining active sessions) has been properly shut down. One parameter to the <a class="el" href="classWt_1_1WServer.html#abca6890dab44d87bd3af64705ac072d3" title="Runs the Wt application server.">WRun()</a> function is a <em>createApplication</em> function object. Alternatively, if you wish to have more control over the application server, you may also instantiate and configure a <a class="el" href="classWt_1_1WServer.html" title="A class encapsulating a web application server.">WServer</a> instance directly.</p>
<p>For every new session (which corresponds to a new user accessing your web application), the library calls your createApplication callback function to create a new <a class="el" href="classWt_1_1WApplication.html" title="Represents an application instance for a single session.">WApplication</a> object for that session. The request arguments (as part of the <a class="el" href="classWt_1_1WEnvironment.html" title="A class that captures information on the application environment.">WEnvironment</a> object) are passed to this createApplication function, and may be used to customize the application or authenticate the user. See also <a class="el" href="overview.html#bootstrap"> 6. Application bootstrap</a> for details on the application bootstrap method.</p>
<p>At all times, the <a class="el" href="classWt_1_1WApplication.html" title="Represents an application instance for a single session.">WApplication</a> instance is accessible using the static method <a class="el" href="classWt_1_1WApplication.html#a38d922da0a0d83395519f3eaab85d0f6" title="Returns the current application instance.">WApplication::instance()</a>, and is useful to inspect startup arguments and settings (using <a class="el" href="classWt_1_1WApplication.html#a19f3b913f4bc2f69761d9a3738bf142b" title="Returns the environment information.">WApplication::environment()</a>), to set or change the application title (<a class="el" href="classWt_1_1WApplication.html#a71a3f7da5abb9a76df94fab69ba61670" title="Sets the window title.">WApplication::setTitle()</a>), to specify a locale (<a class="el" href="classWt_1_1WApplication.html#a5c9cc1350019d69f154a2b44cdaf2596" title="Changes the locale.">WApplication::setLocale()</a>) for rendering, and many other application-wide settings. In a multi-threaded environment, access to this instance is implemented using thread local storage.</p>
<p>A session exits when the user browses away from the application, when <a class="el" href="classWt_1_1WApplication.html#a5231d54ed34982f4366058eb6440c8f7" title="Quits the application.">WApplication::quit()</a> is called, or when the application server is shut down. In any case, the application object together with the entire widget tree for that session is first properly deleted. Therefore, you should release resources held by your widgets or application in the destructors of these objects.</p>
<p>The library offers two different mechanisms to map sessions onto processes: <b>dedicated processes</b> (only with FastCGI deployment) and <b>shared processes</b>. The first mechanisms forks a dedicated process for every distinct session. This provides the kernel-level isolation of different sessions, which may be useful for highly security sensitive applications. The second mechanism spawns a number of processes and allocates new sessions randomly to one of these processes (when using the built-in httpd, only one process is used in total). This reduces the danger for DoS attacks, but requires more careful programming as memory corruption affects all sessions in a single process, and sessions are not isolated by any other mechanism but correct programming.</p>
<h2><a class="anchor" id="signal_slot"></a>
4. Signal/slot event handling</h2>
<p>To respond to user-interactivity events, or in general to communicate events from one widget to any other, Wt uses a signal/slot system.</p>
<p>A slot can be any function, bound using boost::bind() or std::bind(), but special support exists for method of descendants of <a class="el" href="classWt_1_1WObject.html" title="A base class for objects that participate in the signal/slot system.">WObject</a> with respect to connection management: the signal will be disconnected when the bound object is deleted.</p>
<p>To connect a signal with a slot, the only requirement is that the method signature of the slot must be compatible with the signal definition. In this way every method may be used as a slot, and it is not necessary to explicitly indicate a particular method to be a slot (as is needed in Qt), by putting them in a special section. Nevertheless, you may still do that if you wish to emphasize that these functions can be used as slots, or, if you have done extra work to optimize the implementation of these methods as client-side JavaScript code (see below).</p>
<p>A signal may be created by adding a <a class="el" href="classWt_1_1Signal.html">Signal<X, ...></a> object. You may specify up to 6 arguments which may be of arbitrary types that are Copyable, that may be passed through the signal to connected slots.</p>
<p>The library defines several user-event signals on various widgets, and it is easy and convenient to add signals and slots to widget classes to communicate events and trigger callbacks.</p>
<p>Event signals (<a class="el" href="classWt_1_1EventSignal.html">EventSignal<E></a>) are signals that may be triggered internally by the library to respond to user interactivity events. The abstract base classes <a class="el" href="classWt_1_1WInteractWidget.html" title="An abstract widget that can receive user-interface interaction.">WInteractWidget</a> and <a class="el" href="classWt_1_1WFormWidget.html" title="An abstract widget that corresponds to an HTML form element.">WFormWidget</a> define most of these event signals. To react to one of these events, the programmer connects a self-defined or already existing slot to such a signal.</p>
<h2><a class="anchor" id="eventhandling"></a>
5. Optimizing client-side event handling</h2>
<p>By default, Wt performs all event processing server-side. Every connected event signal will cause the web browser to communicate with the web server in order to invoke the call-back code, and visual changes will be updated in the web page.</p>
<p>However, Wt offers several options for incorporating client-side event handling. This may in general increase responsiveness of the application since the user gets an instant feed-back, avoiding the typical communication delay is avoided.</p>
<p>The least flexible but most convenient option for client-side event handling is letting Wt learn the visual effect of a slot and cache it in JavaScript code in the browser. In this way, the functionality is still specified in C++, and therefore the application still works equally when JavaScript is not available. The only restriction is that this is only possible for stateless call-back code -- i.e. when the visual update does not depend on state that may change in the course of the application, or event details. See the documentation of <a class="el" href="classWt_1_1WObject.html#adaa163b9e92933f3b2ff4ec58e2734c6" title="Declares a slot to be stateless and learn client-side behaviour on first invocation.">WObject::implementStateless</a> for details, or the <a class="el" href="example.html">Treelist example</a> for the use of stateless implementations to create a treelist widget that does all node expansion / collapsing client-side, at least if JavaScript is available.</p>
<p>The stateless slot learning allows applications to be developed entirely in C++, with only one specification of the desired behaviour, and decide at run-time to optimize certain event handling in client-side JavaScript if possible, and fall-back to server-side event handling otherwise.</p>
<p>When the requirements for stateless slot learning cannot be met you will have to resort to writing JavaScript manually. Wt provides a number of mechanisms to integrate JavaScript code with C++:</p>
<ul>
<li>Using <a class="el" href="classWt_1_1JSlot.html" title="A slot that is only implemented in client side JavaScript code.">JSlot</a>, you can specify the JavaScript for a slot, when connected to an <a class="el" href="classWt_1_1EventSignal.html" title="A signal that conveys user-interface events.">EventSignal</a>.</li>
</ul>
<ul>
<li>Using <a class="el" href="classWt_1_1JSignal.html" title="A signal to relay JavaScript to C++ calls.">JSignal</a>, you can emit a C++ signal from JavaScript code, using a JavaScript function <code>Wt.emit()</code>.</li>
</ul>
<ul>
<li>Using <a class="el" href="classWt_1_1WApplication.html#a2a92457b9212cef4057cb54e56183967" title="Executes some JavaScript code.">WApplication::doJavaScript()</a>, you can call JavaScript code directly as part of event handling.</li>
</ul>
<h2><a class="anchor" id="bootstrap"></a>
6. Application bootstrap</h2>
<p>A Wt application may support both plain HTML and Ajax-enabled user agents. When a first request is made for a new session, there is no way of knowing whether the agent supports Ajax (and has it enabled). The bootstrap procedure therefore has two strategies of making the choice between a plain HTML and Ajax-enabled application mode.</p>
<h3><a class="anchor" id="default_bootstrap"></a>
6.1 Default bootstrap</h3>
<p>In the default bootstrap mode, for the normal case, a small bootstrap HTML file is served, which detects presence of Ajax (and various other environment properties such as presence of an internal path as an anchor, cookie support, and IE VML DPI setting). If no JavaScript support is available, it automatically redirects the user to a plain HTML version of the application.</p>
<p>In this mode, the application is not started until the library has determined Ajax support, which is made available in <a class="el" href="classWt_1_1WEnvironment.html#af39702064f91a549514f28de713b7cd2" title="Returns whether the browser has enabled support for AJAX.">WEnvironment::ajax()</a> which is passed to the application constructor.</p>
<p>In some special cases, this bootstrap is skipped and a plain HTML version is served. This is for user agents that are identified as spider bots, or user agents which are configured to not support Ajax (well), see the <a class="el" href="overview.html#config_general">user-agents configuration setting</a>.</p>
<p>There are some draw-backs to this bootstrap method:</p>
<ul>
<li>the redirection without JavaScript support may not be supported by all user agents, leaving these with a link and a redirect message (see the <a class="el" href="overview.html#config_general">redirect-message configuration</a> setting")</li>
</ul>
<ul>
<li>there is an additional round-trip before any contents is rendered</li>
</ul>
<ul>
<li>for an Ajax user interface, all contents will be loaded through JavaScript. This has a draw-back that some 3rd party JavaScript libraries do not support being loaded on-demand (with as most notable example, Google ads).</li>
</ul>
<h3><a class="anchor" id="progressive_bootstrap"></a>
6.1 Progressive bootstrap</h3>
<p>Since Wt 2.99.4, a new bootstrap method has been added (initially proposed by Anthony roger Buck). While the default bootstrap already honors the principle of graceful degradation, this bootstrap implements this using the principle of <a href="http://en.wikipedia.org/wiki/Progressive_enhancement">progressive enhancement</a> (and quite literally so).</p>
<p>This bootstrap method may be enabled with the <a class="el" href="overview.html#config_general">progressive-bootstrap configuration setting</a>.</p>
<p>This bootstrap method will initially assume that the user agent is a plain HTML user-agent and immediately create the application (with <a class="el" href="classWt_1_1WEnvironment.html#af39702064f91a549514f28de713b7cd2" title="Returns whether the browser has enabled support for AJAX.">WEnvironment::ajax()</a> always returning <code>false</code>). The initial response will contain the initial page suitable for a plain HTML user-agent.</p>
<p>JavaScript embedded in this page will sense for Ajax support and trigger a second request which progresses the application to an Ajax application (without repainting the user interface). To that extent, it will change <a class="el" href="classWt_1_1WEnvironment.html#af39702064f91a549514f28de713b7cd2" title="Returns whether the browser has enabled support for AJAX.">WEnvironment::ajax()</a> to return <code>true</code>, and invoke <a class="el" href="classWt_1_1WApplication.html#a78016406c4746c56b2c2ffce7c5e181f" title="Progresses to an Ajax-enabled user interface.">WApplication::enableAjax()</a> which in turn propagates <a class="el" href="classWt_1_1WWidget.html#a919a4eaf68ff52f06f6a726d55dfb768" title="Progresses to an Ajax-enabled widget.">WWidget::enableAjax()</a> through the widget hierarchy. This upgrade happens in the back-ground, unnoticed to the user.</p>
<p>This mitigates disadvantages associated with the default bootstrap, but has the drawback of requiring consistent enableAjax() implementations and requiring more server-side processing.</p>
<h2><a class="anchor" id="sec_painting"></a>
7. Painting</h2>
<p>Wt provides a vector graphics painting system which depending on the browser support uses one of three different methods to paint the graphics (inline SVG, inline VML or HTML 5 <canvas> element). Vector graphics has as benefit a lower bandwidth usage, which is indepedent of the image size and quality, and can be embedded within the HTML, avoiding an additional round-trip. To use the paint system, you need to specialize <a class="el" href="classWt_1_1WPaintedWidget.html" title="A widget that is painted using vector graphics.">WPaintedWidget</a> and use a <a class="el" href="classWt_1_1WPainter.html" title="Vector graphics painting class.">WPainter</a> to paint the contents of the widget inside its <a class="el" href="classWt_1_1WPaintedWidget.html#ad8ce22eff41754c8616f45851f57fb1a" title="Paints the widget.">WPaintedWidget::paintEvent()</a>.</p>
<h2><a class="anchor" id="internationalization_sec"></a>
8. Internationalization</h2>
<p>Wt's <a class="el" href="classWt_1_1WString.html" title="A value class which describes a locale-aware unicode string.">WString</a> class offers an interface to translate strings by using the static <a class="el" href="classWt_1_1WString.html#a0afc7dc0f9897456d71b569a86ca26c1" title="Creates a localized string from a key.">WString::tr</a>("key") method to construct a <a class="el" href="classWt_1_1WString.html" title="A value class which describes a locale-aware unicode string.">WString</a>. These key values will be lookup up in so-called message resource bundles (see <a class="el" href="classWt_1_1WMessageResourceBundle.html" title="Support for localized strings using XML files.">WMessageResourceBundle</a>). These are a set of xml files that translate the keys to a localized string. The name of the xml file determines the language contained therein (e.g. foo.xml, foo-nl.xml, foo-cn.xml)</p>
<p>The strings that are used by classes within the Wt library use the same system to translate their strings. English messages will be used by default and are built into Wt. If you want to translate e.g. the months of a <a class="el" href="classWt_1_1WCalendar.html" title="A calendar.">WCalendar</a>, copy src/xml/wt.xml and translate them to your language of choice. From then on, you can call <a class="el" href="classWt_1_1WMessageResourceBundle.html#a01368946b2a2aaceab3a64cddb1cb1e2" title="Adds a (series) of message resource files to be used.">WMessageResourceBundle::use()</a> in your application and use your own replacement XML files, which will take precedence over the built-in translations.</p>
<p>Wt also supports plural forms of nouns, to translate such string use the static <a class="el" href="classWt_1_1WString.html#abcff7d3d30972762bd5d9279dc903a36" title="Creates a localized string from a key for a number n.">WString::trn</a>("key", n) function. The <a class="el" href="classWt_1_1WMessageResourceBundle.html" title="Support for localized strings using XML files.">WMessageResourceBundle</a> class documentation contains an example on how to format the xml resource bundle to use this functionality.</p>
<h2><a class="anchor" id="deployment"></a>
9. Deployment</h2>
<p>The library is designed so that, besides the application binary, only files from the <code>resources/</code> folder are needed to deploy the application. The resources folder contains icons, style sheets associated with themes, and other resources specific for special widgets. The URL at which the <code>resources/</code> folder is deployed is based on the <em>resourcesURL</em> configuration property (see see <a class="el" href="overview.html#config_general">configuration properties</a>), which defaults to "/resources".</p>
<p>In addition, you may need to deploy also your own CSS files, custom icons/images, and/or static pages that you reference from your application, into your web server.</p>
<p>Your application may also use other files which do not need to be published online, but are instead read only by your application. These files include message resource files (containing localized text strings), the wt configuration file, your own configuration files, etc... You can deploy these to an <em>application root</em> (see <a class="el" href="classWt_1_1WApplication.html#a88b082dadadd3fb7dbe10887e7d89c91" title="Returns the appRoot special property.">WApplication::appRoot()</a>), whose location is configured in a way that is specific for each connector.</p>
<h3><a class="anchor" id="fastcgi"></a>
9.1 FastCGI</h3>
<p>When linking your application against <code>libwtfcgi</code>, the resulting binary is a FastCGI binary. This binary may then be deployed and managed within a web server which supports the FastCGI protocol (these include apache, lighttpd and many other popular web servers).</p>
<p>The following locations for the wt_config.xml configuration file are considered, in this order:</p>
<ul>
<li>value of environment variable <code>$WT_CONFIG_XML</code></li>
<li>within the app root, as configured by the environment variable <code>$WT_APP_ROOT</code>: <code>$WT_APP_ROOT/wt_config.xml</code></li>
<li>the compile-time default (<code>/etc/wt/wt_config.xml</code>),</li>
</ul>
<p>Environment variables can be specified to a FastCGI application depending on the web server. E.g. for FastCGI, this is:</p>
<div class="fragment"><pre class="fragment">-initial-env WT_APP_ROOT=/opt/myapp
</pre></div><h3><a class="anchor" id="wthttpd"></a>
9.2 Built-in httpd</h3>
<p>When linking your application against <code>libwthttp</code>, the resulting binary is a stand-alone HTTP/WebSockets server. The web server will act as a plain web server in addition to serving the Wt application.</p>
<p>The following locations for the wt_config.xml configuration file are considered, in this order:</p>
<ul>
<li>command-line parameter <code>--config</code> or <code>-c</code></li>
<li>value of environment variable <code>$WT_CONFIG_XML</code></li>
<li>within the appRoot, as configured by command line paramater <code>--approot</code>, or the environment variable <code>$WT_APP_ROOT</code>: appRoot<code>/wt_config.xml</code></li>
<li>the compile-time default (<code>/etc/wt/wt_config.xml</code>)</li>
</ul>
<p>Use the <code>--deploy-path</code> parameter to deploy the application at a specific URL. By default, the application is deployed at '/'.</p>
<p>When the application is deployed at a path ending with '/' (i.e. a folder path), only an exact match for a requested URL will be routed to the application itself. This behaviour avoids deployment problems with the singular case where you deploy at '/' and no static files would be served by the web server. As a consequence, ugly URLs will be generated for internal paths. Since version 3.1.9, it is however possible to have clean URLs also when deploying at the root by specifically listing the folders that contain static assets in --docroot, followed by ';':</p>
<div class="fragment"><pre class="fragment">$ ../../build/examples/wt-homepage/Home.wt --docroot=<span class="stringliteral">".;/favicon.ico,/css,/resources,/style,/icons"</span> ...
</pre></div><h3><a class="anchor" id="wtisapi"></a>
9.3 ISAPI</h3>
<p>When linking your application against <code>wtisapi</code>, the resulting binary is an ISAPI plugin. This DLL may then be deployed and managed within Microsoft IIS.</p>
<p>The following locations for the wt_config.xml configuration file are considered, in this order:</p>
<ul>
<li>within the app root, as configured by the INI file which has the same name as the application DLL, but with .INI append to it (e.g. <tt>C:\Program Files\WtApplications\Public\MyApplication.dll.ini</tt> ): <pre>
[isapi]
appRoot=C:\Program Files\MyApplications\AppRoot
</pre> </li>
<li>the compile-time default (<code>/etc/wt/wt_config.xml</code>)</li>
</ul>
<h2><a class="anchor" id="configuration_sec"></a>
10. Configuration</h2>
<p>Wt has one main XML configuration file, which by default is located in <code>/etc/wt/wt_config.xml</code>, but whose location can be overridden use environment settings and/or commandline parameters that are connector specific (see the connector supra).</p>
<p>The configuration file may specify several <b><application-settings></b>. The settings that apply are determined by the <em>location</em> attribute. Application settings for the '*' location are general settings, which may be overridden on a per-application level by settings with a location attribute that matches the location of the application (on the file system).</p>
<h3><a class="anchor" id="config_session"></a>
10.1 Session management (wt_config.xml)</h3>
<p>These are options related to session management, and are specified inside <b><session-management></b> subsection.</p>
<dl>
<dt><b>dedicated-process</b> </dt>
<dd><p class="startdd">Every session is mapped a dedicated process, allowing maximal session isolation, but at an increased session cost. <br/>
This is currently only supported using the FastCGI connector.</p>
<p class="enddd"></p>
</dd>
<dt><b>shared-process</b> </dt>
<dd><p class="startdd">Sessions share a fixed number of processes, yielding a lower session cost. <br/>
This is the only option for the Wthttpd connector.</p>
<p class="enddd"></p>
</dd>
<dt><b>tracking</b> </dt>
<dd><p class="startdd">How session tracking is implemented: automatically (using cookies when available, otherwise using URL rewriting) or strictly using URL rewriting (which allows multiple concurrent sessions from one user). </p>
<p class="enddd"></p>
</dd>
<dt><b>reload-is-new-session</b> </dt>
<dd><p class="startdd">Should a brower reload spawn a new session (convenient for debugging) or simply refresh (using <a class="el" href="classWt_1_1WApplication.html#a02b9d8aa1b6c2d0dc9edc1b9c63f86dc" title="Refreshes the application.">WApplication::refresh()</a>) the current session ? This setting may have implications for the URL that is displayed, because session information in needed in the URL to handle the reload within the current session.</p>
<p class="enddd"></p>
</dd>
<dt><b>timeout</b> </dt>
<dd><p class="startdd">The timeout (in seconds) for detecting an idle session. A Wt application uses a keep-alive messages to keep the session alive as long as the user is visiting the page. Increasing this number will result in a longer time between keep-alive message, resulting in a lower server load, but at the same time will detect a dead session with a longer delay, and thus have on average more sessions in memory that are no longer used.</p>
<p class="enddd"></p>
</dd>
<dt><b>server-push-timeout</b> </dt>
<dd><p class="startdd">When using server-initiated updates, the client uses long-polling requests or WebSockets. Proxies (including reverse proxies) are notorious for silently closing idle requests; the client therefore cancels the long polling request after a timeout, and starts a new one, or does a ping/pong message over the WebSocket connection.</p>
<p class="enddd"></p>
</dd>
</dl>
<h3><a class="anchor" id="config_general"></a>
10.2 General application settings (wt_config.xml)</h3>
<p>These options are indicated directly within <b><application-settings></b>, and specify settings that affect the run-time behaviour of the application.</p>
<dl>
<dt><b>debug</b> </dt>
<dd><p class="startdd">When debugging is enabled, JavaScript errors are not caught, and thus will provide stack information when using a JavaScript debugger.</p>
<p class="enddd"></p>
</dd>
<dt><b>log-file</b> </dt>
<dd><p class="startdd">Path to the log file used for application logging (see Wt::log()). If not specified, logging is directed to stderr, which depending on the connector used ends up in the server error log, into the big void, or, simply to stderr. </p>
<p class="enddd"></p>
</dd>
<dt><b>log-config</b> </dt>
<dd><p class="startdd">Configuration for the built-in logger, which is passed on to <a class="el" href="classWt_1_1WLogger.html#a567c5b28fee703e37523898d30016f40" title="Configures what things are logged.">WLogger::configure()</a></p>
<p class="enddd"></p>
</dd>
<dt><b>max-request-size</b> </dt>
<dd><p class="startdd">The maximum HTTP request size (Kb) that is accepted. An oversized request will result in a <a class="el" href="classWt_1_1WApplication.html#a5ebdb82053d80b17d5ac7affd8dc7fa2" title="Signal which indicates that too a large request was received.">WApplication::requestTooLarge()</a> signal. </p>
<p class="enddd"></p>
</dd>
<dt><b>session-id-length</b> </dt>
<dd><p class="startdd">The length (in number of characters) for the unique session ID.</p>
<p class="enddd"></p>
</dd>
<dt><b>session-id-prefix</b> </dt>
<dd><p class="startdd">A fixed prefix for the session ID. You can use this to implement aid a load-balancer to figure out the destination for a particular request.</p>
<p class="enddd"></p>
</dd>
<dt><b>plain-ajax-sessions-ratio-limit</b> </dt>
<dd><p class="startdd">DoS prevention: limit plain HTML sessions. This is a simple measure which avoids Denial-of-Service attacks on plain HTML sessions, which are easy to mount in particular in the case of progressive bootstrap mode. This setting may be used to keep the ratio of plain HTML versus Ajax sessions under a certain ratio. Typically, most of your sessions will be Ajax sessions, and only a tiny fraction (e.g. less than 5%) will be plain HTML sessions. This ratio is only enforced when more than 20 sessions have been created. </p>
<p class="enddd"></p>
</dd>
<dt><b>ajax-puzzle</b> </dt>
<dd><p class="startdd">DoS prevention: adds a puzzle to validate Ajax sessions. This is a simple measure which avoids Denial-of-Service attacks on Ajax sessions. When enabled, a puzzle needs to be solved in the first Ajax request which eliminates agents that do not build a proper DOM tree. </p>
<p class="enddd"></p>
</dd>
<dt><b>send-xhtml-mime-type</b> </dt>
<dd><p class="startdd">Whether the application presents rendered content as XHTML or HTML. Wt always renders XHTML1 compatible HTML, but by default indicates to the browser that it is in fact HTML. Before the adoption of HTML5, use inline SVG (see <a class="el" href="classWt_1_1WSvgImage.html" title="A paint device for rendering using Scalable Vector Graphics (SVG).">WSvgImage</a>), it was necessary to present an XHTML mime type. Setting this option will do so only for browsers that indicate support for XHTML. Nowadays, this option is rarely useful.</p>
<p class="enddd"></p>
</dd>
<dt><b>web-sockets</b> </dt>
<dd><p class="startdd">By default Ajax and long polling are used to communicate between server and browser.</p>
<p>By enabling web socket support, if the browser supports WebSockets, then WebSocket is the protocol used for communication between client and server. WebSockets are currently only supported by the built-in httpd Connector, which acts as both an HTTP and WebSocket server, multiplexed on the same port(s).</p>
<p>Wt implements the final Web Sockets RFC candidate, as well as all prior drafts.</p>
<p class="enddd"></p>
</dd>
<dt><b>redirect-message</b> </dt>
<dd><p class="startdd">When the default bootstrap method is used, this message is used in the link which redirects to the user to a plain HTML version, in case his user agent does not support the automatic redirect.</p>
<p class="enddd"></p>
</dd>
<dt><b>behind-reverse-proxy</b> </dt>
<dd><p class="startdd">When enabling this option to indicate that the application is deployed behind a reverse proxy (as would be common if you use the wthttpd connector), the server location is not read from the "Host" header, but from the <code>X-Forwarded-For</code> header, if present.</p>
<p class="enddd"></p>
</dd>
<dt><b>user-agents</b> </dt>
<dd><p class="startdd">Wt considers three types of sessions: </p>
<ul>
<li>
Ajax sessions: use Ajax and JavaScript </li>
<li>
plain HTML sessions: use plain old server POSTs </li>
<li>
bots: have clean internal paths, no persistent sessions, no html <form> elements, and no auto-generated DOM element id's. </li>
</ul>
<p></p>
<p>By default, Wt does a browser detection to distinguish between the first two: if a browser supports JavaScript (and has it enabled), and has an Ajax DOM API, then Ajax sessions are chosen, otherwise plain HTML sessions.</p>
<p></p>
<p>Here, you may indicate which user agents should or should not receive an Ajax session regardless of what they report as capabilities, and which user agents should be treated as search bots. You can define three types of <user-agents> lists:</p>
<ul>
<li><code>type="ajax" mode="white-list"</code>: these are the only user agents that are considered as Ajax-capable.</li>
<li><code>type="ajax" mode="black-list"</code>: these are user agents that are not considered as Ajax-capable.</li>
<li><code>type="bot"</code>: these are user-agents that are treated as bots. </li>
</ul>
<p>Example:</p>
<div class="fragment"><pre class="fragment"><user-agents type=<span class="stringliteral">"bot"</span>>
<user-agent>.*Googlebot.*</user-agent>
<user-agent>.*msnbot.*</user-agent>
<user-agent>.*Slurp.*</user-agent>
<user-agent>.*Crawler.*</user-agent>
<user-agent>.*Bot.*</user-agent>
<user-agent>.*ia_archiver.*</user-agent>
<user-agent>.*Twiceler.*</user-agent>
<user-agent>Yandex.*</user-agent>
<user-agent>.*Nutch.*</user-agent>
<user-agent>.*MJ12bot.*</user-agent>
<user-agent>Baiduspider.*</user-agent>
</user-agents>
</pre></div><p></p>
<p class="enddd"></p>
</dd>
<dt><b>progressive-bootstrap</b> </dt>
<dd><p class="startdd">This boolean configuration option configures which bootstrap method is used, see <a class="el" href="overview.html#bootstrap"> 6. Application bootstrap</a>. </p>
<p class="enddd"></p>
</dd>
<dt><b>properties</b> </dt>
<dd>Application-specific properties which may be accessed using <a class="el" href="classWt_1_1WApplication.html#ac0f5599ed35eb159fa6912aa0ff3c75c" title="Reads a configuration property.">WApplication::readConfigurationProperty()</a>. For example: <div class="fragment"><pre class="fragment"> <properties>
<<span class="keyword">property</span> name=<span class="stringliteral">"extBaseURL"</span>>/ext/</<span class="keyword">property</span>>
<<span class="keyword">property</span> name=<span class="stringliteral">"resourcesURL"</span>>/resources</<span class="keyword">property</span>>
<<span class="keyword">property</span> name=<span class="stringliteral">"appRoot"</span>>/opt/myapp</<span class="keyword">property</span>>
</properties>
</pre></div> </dd>
</dl>
<h3><a class="anchor" id="config_fastcgi"></a>
10.3 FastCGI options (wt_config.xml)</h3>
<p>These options only apply to FastCGI-based deployment, and are are specified inside a <b><connector-fcgi></b> subsection.</p>
<dl>
<dt><b>valgrind-path</b> </dt>
<dd><p class="startdd">Set the path to valgrind for debugging using valgrind. This requires that debugging is enabled and <code>debug</code> is passed to the application as last request parameter.</p>
<p class="enddd"></p>
</dd>
<dt><b>run-directory</b> </dt>
<dd>The path that is used by the library for managing sessions. </dd>
</dl>
<h3><a class="anchor" id="config_wthttpd"></a>
10.4 Wt httpd (command-line or configuration file) options</h3>
<p>These options are not specified in the wt_config.xml configuration file, but may be indicated on the command-line, or within a configuration file that is located at /etc/wt/wthttpd.</p>
<p>The configuration file syntax is line based: </p>
<ul>
<li>
<p class="startli"></p>
<p>A line in the form: </p>
<p><code>name = value</code> </p>
<p>gives a value to an option. </p>
<p class="endli"></p>
</li>
<li>
<p class="startli"></p>
<p class="endli">The <code>#</code> character introduces a comment that spans until the end of the line. </p>
</li>
</ul>
<div class="fragment"><pre class="fragment">Allowed options:
General options:
-h [ --help ] produce help message
-t [ --threads ] arg (=10) number of threads
--servername arg (=vierwerf) servername (IP address or DNS name)
--docroot arg document root for static files, optionally
followed by a comma-separated list of paths
with static files (even if they are within a
deployment path), after a ';'
e.g. --docroot=".;/favicon.ico,/resources,/style"
--approot arg application root for private support files; if
unspecified, the value of the environment
variable $WT_APP_ROOT is used, or else the
current working directory
--docroot-static arg comma-separated list of paths that correspond
to static files, even if they are within a
deployment path
--errroot arg root for error pages
--accesslog arg access log file (defaults to stdout)
--no-compression do not use compression
--deploy-path arg (=/) location for deployment
--session-<span class="keywordtype">id</span>-prefix arg prefix for session-<span class="keywordtype">id</span>'s (overrides
wt_config.xml setting)
-p [ --pid-file ] arg path to pid file (optional)
-c [ --config ] arg location of wt_config.xml; if unspecified, the
value of the environment variable
$WT_CONFIG_XML is used, or else the built-in
default (/etc/wt/wt_config.xml) is tried, or
else built-in defaults are used
--max-memory-request-size arg threshold for request size (bytes), for
spooling the entire request to disk to avoid,
to avoid DoS
--gdb do not shutdown when receiving Ctrl-C (and let
gdb break instead)
HTTP/WebSocket server options:
--http-address arg IPv4 (e.g. 0.0.0.0) or IPv6 Address (e.g. 0::0)
--http-port arg (=80) HTTP port (e.g. 80)
HTTPS/Secure WebSocket server options:
--https-address arg IPv4 (e.g. 0.0.0.0) or IPv6 Address (e.g. 0::0)
--https-port arg (=443) HTTPS port (e.g. 443)
--ssl-certificate arg SSL server certificate chain file
e.g. "/etc/ssl/certs/vsign1.pem"
--ssl-private-key arg SSL server private key file
e.g. "/etc/ssl/private/company.pem"
--ssl-tmp-dh arg File for temporary Diffie-Hellman parameters
e.g. "/etc/ssl/dh512.pem"
Settings may be set in the configuration file /etc/wt/wthttpd
</pre></div><h3><a class="anchor" id="config_isapi"></a>
10.5 ISAPI options (wt_config.xml)</h3>
<p>These options only apply to ISAPI-based deployment, and are are specified inside a <b><connector-isapi></b> subsection.</p>
<dl>
<dt><b>num-threads</b> </dt>
<dd><p class="startdd">Sets the number of threads to be used to handle Wt traffic. The connector will never use IIS threads to do any processing, but will forward the requests to a thread pool of the size given in this variable. Depending on your application, you may want to increase the default size of 10 threads.</p>
<p class="enddd"></p>
</dd>
<dt><b>max-memory-request-size</b> </dt>
<dd>Every HTTP request whose size is smaller than this parameter will be buffered in memory. Larger requests, such as large file uploads, will be spooled to a file. You probably do not want to change this parameter. </dd>
</dl>
<h2><a class="anchor" id="error_sec"></a>
11. Error-handling and logging</h2>
<p>Wt provides logging of events to a log-file (see the <a class="el" href="overview.html#config_general">log-file configuration setting</a>). Every log entry has a timestamp, the process id and the session id. Wt uses four different event types, from least to most severe:</p>
<dl>
<dt><b>notice</b> </dt>
<dd><p class="startdd">Informational notices. These are events that may be interesting for late analysis of other problems, for performance analysis, or estimating server load.</p>
<p></p>
<p>Generated using Wt::log(), e.g.: </p>
<div class="fragment"><pre class="fragment">Wt::log(<span class="stringliteral">"info"</span>) << <span class="stringliteral">"Message"</span>;
</pre></div> <p class="enddd"></p>
</dd>
<dt><b>warn</b> </dt>
<dd><p class="startdd">Warnings. These events are generated when you are using the API in a way that may not have been as intended.</p>
<p></p>
<p>Generated using Wt::log(), e.g.: </p>
<div class="fragment"><pre class="fragment">Wt::log(<span class="stringliteral">"warn"</span>) << <span class="stringliteral">"Message"</span>;
</pre></div> <p class="enddd"></p>
</dd>
<dt><b>error</b> </dt>
<dd><p class="startdd">Non-fatal application errors. These errors indicate for example unexpected input from the web browser or application user, XML parsing problems, but not necessarily a programming error.</p>
<p></p>
<p>Generated using Wt::log(), e.g.: </p>
<div class="fragment"><pre class="fragment">Wt::log(<span class="stringliteral">"error"</span>) << <span class="stringliteral">"Message"</span>;
</pre></div> <p class="enddd"></p>
</dd>
<dt><b>secure</b> </dt>
<dd><p class="startdd">Non-fatal security errors and/or notices.</p>
<p class="enddd"></p>
</dd>
<dt><b>fatal</b> </dt>
<dd><p class="startdd">Fatal application errors. These errors terminate the current session (but not the application server), and are errors that indicate a programming error. For example, this error is triggered by misuses of the API.</p>
<p></p>
<p class="enddd">Generated by throwing a std::exception. </p>
</dd>
</dl>
<p>You can now proceed to <a class="el" href="InstallationUnix.html">Installation: Unix-like platforms</a> or <a class="el" href="InstallationWindows.html">Installation: Windows</a> </p>
</div></div>
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
onkeydown="return searchBox.OnSearchSelectKey(event)">
<a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(0)"><span class="SelectionMark"> </span>All</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(1)"><span class="SelectionMark"> </span>Classes</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(2)"><span class="SelectionMark"> </span>Namespaces</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(3)"><span class="SelectionMark"> </span>Files</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(4)"><span class="SelectionMark"> </span>Functions</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(5)"><span class="SelectionMark"> </span>Variables</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(6)"><span class="SelectionMark"> </span>Typedefs</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(7)"><span class="SelectionMark"> </span>Enumerations</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(8)"><span class="SelectionMark"> </span>Enumerator</a></div>
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
</div>
<hr size="1"><address style="text-align: right; margin: 3px"><small>
Generated on Thu Nov 1 2012 for <a href="http://www.webtoolkit.eu/wt">the
C++ Web Toolkit (Wt)</a> by <a
href="http://www.doxygen.org/index.html"><img src="doxygen.png"
alt="doxygen" border="0" style="vertical-align: middle; display:
inline-block; height: 2em"></a> 1.7.5.1</small></address>
</body>
</html>
