When a widget is inserted in the tree, ownership is transferred to the tree. Whenever a widget is deleted, all its children are deleted as well. When the WApplication object is deleted, the root of the tree is deleted, and in this way all resources associated with any widget are freed.
Any descendent class of WWidget is a self-contained class that encapsulates both the look and behaviour.
CSS layout considers two important categories of layout. Text-like layout (inline) flow with sibling inline widgets in lines, wrapping at the right edge of the parent container. In contrast, stacked widgets stack vertically with respect to sibling widgets.
CSS Style selectors may be used in conjunction with widget style classes that may be set for any widget using Wt::WWidget::setStyleClass(). The recommended way for visual response to events is by changing the style class for the widget.
In addition to configuration using style sheets, Wt also supports inline specification of style, using Wt::WWidget::decorationStyle().
At all times, the WApplication instance is accessible using WApplication::instance(), and may be used to inspect startup arguments and settings (using Wt::WApplication::environment()), to set or change the application title (Wt::WApplication::setTitle()), to specify a locale (Wt::WApplication::setLocale()) for rendering, and many other application-wide settings.
An application is exited when the user browses away from the application, when WApplication::quit() is called, or when the application server is shut down. In either case, the entire widget tree is properly deleted. Therefore, you should release resources held by your widgets or application in the destructors of these objects.
As of version 2.0.0, the library offers two different mechanisms to map sessions onto processes: dedicated processes (only with FastCGI deployment) and shared processes. 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.
A slot is any method of any descendant of Wt::WObject. 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. While in this way every method may be used as a slot, we encourage to explicitly indicate a particular method to be a slot, in the same way as is done in Qt, by putting them in a special section (which improves for example documentation generated using doxygen):
class MyWidgetry : public Wt::WCompositeWidget { // ... public slots: void doThis(); private slots: void doThat(int count); // ... };
A signal may be created for an object by instantiating a Wt::Signal<> class.
The library defines several userevent signals on various widgets, and it is easy and convenient to add signals and slots to widget classes to communicate events and trigger callbacks.
Event signals (Wt::EventSignal) are signals that may be triggered internally by the library to respond to user interactivity events. Together, the abstract classes Wt::WInteractWidget and Wt::WFormWidget, which are baseclasses of many widgets, provide most of these event signals. Thus, to react to one of these events, the programmer connects a self-defined or already existing slot to the signal.
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.
The least flexible but most convenient option for client-side event handling is letting Wt learn the visual effect of a slot and cache 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 Wt::WObject::implementStateless for details, or the Treelist example 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.
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.
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++:
General options:
-h [ --help ] produce help message
-t [ --threads ] arg (=10) number of threads
--docroot arg document root for static files
--no-compression do not compress dynamic
text/html and text/plain
responses
--deploy-path arg (=/) location for deployment
-p [ --pid-file ] arg (=/var/run/wthttpd.pid) path to pid file (for
monitoring)
HTTP 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 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"
You can now proceed to the Treelist example
1.4.7