Deployment Architecture
Communication over the HTTP protocol with a web browser is abstracted in Wt using a Connector implementation. Two Connector implementations are available in Wt 2.x. One connector uses the FastCGI protocol, which lets Wt applications run in conjunction with many web servers via FastCGI plug-ins. A second connector contains a lightweight, built-in web server, so that Wt applications can be developed and deployed without need for a third-party web server.
The open FastCGI protocol was initially designed to allow CGI applications to be long lived and handle multiple requests. A plug-in in the web server forwards requests corresponding to a specific web application through a local socket to such a long-lived process. This process implements a Wt dispatching server, which identifies the session that is targeted by the request and forwards it to the process that implements this session.
On the other hand, using the built-in web server avoids the need for an intermediate protocol by listening for HTTP(S) requests. In such a deployment scenario, a robust web server may still be used as a front-end web server, which is then configured to proxy pass requests to the Wt application. Because of its small footprint, the built-in web server is also a well-suited standalone for embedded applications. Perhaps most importantly, the built-in web server simplifies the development of Wt applications, because you may start them easily in your debugger, and they have a process and thread structure that may be configured to be as simple as a single thread in a single process, which includes the web server.
The World Is Not Enough
Unlike desktop applications, web applications are automatically available to an international audience. To enable this opportunity, Wt provides features to make it straightforward for your application to be localized and internationalized. For localization, Wt provides message resource bundles. A single message resource bundle defines a set of XML files, one for each locale. Each XML file associates localized text or XHTML with message keys.
The Wt API uses WString for all rendered text. WString defines an implicit constructor that takes standard strings (both narrow and wide variants, C and C++), which then represents a literal string. For example:
WText *aText =
new WText("Hello World!");
creates a text widget that simply displays "Hello World."
To make a localized version of the hello-world program, you would instead use the static method WString::tr(key), which for convenience is aliased in WWidget::tr(key) to create a localized string:
WText *text =
new Wtext(tr("hello-world"));
The string that is displayed will now be resolved by looking for the key in the message resource bundles and the current locale. For example, there could be a file "hello-world.xml" with the contents:
<messages>
<message id="
hello-world">Hello World!</message>
</messages>
and a file "hello-world_nl.xml" providing the same contents in locale nl corresponding to Dutch:
<messages>
<message id=
"hello-world">Dag Wereld!</message>
</messages>
How is the locale determined? By default, Wt uses the locale that is reported by the browser. But the locale may also be changed at runtime, using WApplication::setLocale(locale). Here comes the nice part of the story. WApplication::setLocale() will invoke a refresh of the entire application, by calling WApplication::refresh(), which will propagate a WWidget::refresh() through the entire widget tree. During this propagation, all widgets use the new locale to resolve their displayed text elements in the new locale, and any changes are caught by the usual Wt rendering mechanism to be reflected in the browser. This propagation requires no effort from you, even for application-defined widgets.
Internationalization requires support for characters that go beyond the 8-bit western character sets. For this purpose, Wt provides Unicode support for both literal and localized strings. For literal strings, you may specify and access content through narrow, wide, and UTF8 encoded strings, and therefore allow interfacing with legacy code. For localized strings, Wt relies on the extensive support for Unicode and different character encodings available in XML.
