Biggest changes in Wt 3

Let’s step back and review the biggest changes since we started evelopment of the Wt 3 branch (starting at Wt 2.99.0):

Signals are now accessed through an accessor method, rather than being exposed with a public member.

Previously, you would write:

Since 2.99.0, this should be:

The benefit is that signal objects are created only on-demand. Because most signals are not used, this resulted in both runtime and memory improvements.

Rather than using an untyped int for passing a set of enum flags, which is used throughout the API, we are now using a WFlags<E> class (in C++) and an EnumSet<E> (in Java). This allows type-safe combination of different enums, improving compile-time checks. WFlags should not have any runtime overhead. This probably does not require changes to your existing code, though.

The WResource API (C++/Java) has been redesigned and greatly simplified. The new API is simpler (requires only one virtual method to be implemented) and more powerful, providing support for continuations to serve large resources without blocking a thread or requiring large memory usage (currently in C++ only, as this is only supported in the next version of the Java Servlet API).

Resources now have better thread-safety in C++: they are now by default reentrant (requests for a single resource may be handled concurrently) and they are protected from concurrently being destroyed by the main event loop.

In addition, the mechanism for indicating that a resource has been changed and thus needs to be updated in its views, has been improved and sanitized.

The WTreeView (C++/Java) MVC view class has been updated to use a WAbstractItemDelegate (C++/Java) to perform the actual rendering of cells. This allows the view to be customized for specialized rendering of table cells.

In the future, we will extend the default view delegate, WItemDelegate (C++/Java) to support inline editing, but, you can already implement your custom inline editing delegate.

We added a WTestEnvironment (C++/Java), which allows you to write integration and unit tests that involve Wt widgets and objects.

Wt has has always supported both AJAX clients and plain HTML clients. To differentiate between the two, a small bootstrap page was used that sensed for AJAX availability, and which loaded the first page contents either using JavaScript, or by redirecting to a new page.

Some discussions on the mailing list indicated that this could be done better, suggesting a hybrid bootstrap model: the first page could contain already the entire page as plain HTML, and in the back-ground AJAX presence could be detected to upgrade this to a full AJAX interface. This would have several benefits, including a faster initial response (one round trip instead of two) and better support for JavaScript libraries that need to load in the initial request, such as Google Ads.

We finally got around implementing this. When enabled, first a plain HTML session is assumed, and widgets may later be asked to upgrade themselves to their AJAX version (C++/Java). This is the principle of progressive enhancement, right there, entirely automatically embedded in your application !

Future ?

What to expect in the near future? In order to stabilize and polish Wt and JWt 3, we have confined a lot of new developments in private branches. Several of them are looking promising, and will hopefully find their way to Wt 3 in the near future:

We are finalizing an Object-Relational-Mapping (ORM) layer, which might be useful in many web applications. This blog is actually our pilot project to find out how usable the current implementation is (and, it seems, no web framework is considered complete without a blog as example). We can already tell you that it does not use code generation, XML or ugly macro hacks, but instead you can declare the mapping entirely in plain compact C++. More on it later!

Many users have complained that the default look of Wt’s widgets is boring, and we must confess, we have always given priority to functionality rather than looks. We intend to change this with the advent of theme support. All CSS that is currently provided within the inline stylesheet by each widget class, will be pushed out to external style sheets, and a small API has been added to select a particular theme.

It finally occurred to us that many things could be simplified if we admitted to support for XHTML templates. Unlike traditional frameworks, Wt templates will be used to describe the XHTML for a single widget. Within each template, widgets may be instantiated, and strings resolved. This simplifies those situations where you would like to express the layout using XHTML/CSS, rather than using a nested hierarchy of WContainerWidgets.

This blog implementation uses this templating system to display posts, comments, and the authoring dashboard.