Wt Release notes

This file lists important notes on migrating existing applications to newer version of Wt. It lists changes in the library that may break the way you build Wt, the way you configure Wt or the Wt API and behaviour.

Release 2.2.1 (Nov 3, 2008)

This release is as usually a mix of bug fixes, improvements and new features.

We have made a significant change to the MVC system, which will break existing program code in case you have implemented your own models (i.e. deriving from WAbstractItemModel) or views widgets (i.e. components that listen to model changes).

The WAbstractItemModel interface was changed to support hierarchical models. This means that most methods will now take an extra parameter that specifies the parent WModelIndex, and also all signals have now this extra parameter. Because the parameter has a default value of WModelIndex() which corresponds to the top level parent, the API is largely backwards compatible when merely using the model. It is only those classes that reimplement the interface, or listen to signal events, that are affected.

The immediate benefit of the new WAbstracItemModel interface is that it allows us to implement View widgets like the new WTreeView widget.

Release 2.2.0 (Sept 12, 2008)

This release has a rather substantial rewrite (and simplification) of Wt's bootstrapping process. In the past, Wt used a frameset trick to be able to load the AJAX-based skeleton when JavaScript was available. Isntead, now, the entire AJAX-based stuff is loaded directly into the bootstrap page. A benefit of the new approach is that we avoid iframe tricks, which have been deprecated from strict HTML and XHTML. But, it was in fact motivated in the first place to support all major browsers for a new internal path API. This new API allows to fully support URL changes and bookmarks in a unified way (i.e. it works equally when the browser supports AJAX, no JavaScript, or is a bot such as google bot).

As a consequence, this release contains the following changes that may break your application:

The following methods have been deprecated (but are still supported):

Release 2.1.5 (July 25, 2008)

Wt now installs its include files in a Wt/ subdirectory. You may want to change your build files to pick up this new include directory, or, change your code to scope the include files to look like #include<Wt/WLineEdit> instead of #include<WLineEdit>

This release contains the following changes that may break your application:

The following methods and enumerations have been deprecated (but are still supported):

Release 2.1.4 (July 4, 2008)

The following has changed for building Wt:

The following has changed in the wt_config.xml file:

This release should not contain changes that may break your application.

Release 2.1.3 (May 20, 2008)

This release should not contain changes that may break your application.

Release 2.1.2 (April 14, 2008)

The following changes may break your application build:

Release 2.1.1 (April 10, 2008)

This release should not break any of your applications, but we did deprecate some methods and enumeration types. You are advised to migrate to the replacements methods since we will discontinue support for the older ones in the future.

The following methods and enumerations have been deprecated:

The following changes affect run-time behaviour:

Release 2.1.0

The library dependencies have changed slightly.

To build Wt 2.1.0, you need:

Furthermore, the Wt::Ext library has been upgraded and now wraps around the extjs 2.x library, instead of extjs 1.x.

Some API changes may need a porting effort:

Release 2.0.5

Release 2.0.4

Important: 2.0.4a contains a fix for a bug introduced in 2.0.4 that reset the deploy-path in wthttpd.

This release adds a few new features:

Release 2.0.1

This release fixes some build-related problems, as well as smaller bugs. The main improvement in this release is related to use of Wt in resource-constrained embedded systems.

The most visible change is that the dependency on the Xerces C++ XML library was dropped in favour of the much smaller Mini-XML library. The draw-back is a reduction of supported character encodings to only UTF8 and UTF16, next to the default locale character encoding (which is typically an 8-bit flavour).

When using the built-in httpd, you can now disable support for SSL at compile time, freeing a number of SSL-related dependencies.

In the API, more comparison operators (== and !=) were added to WString, and a WViewWidget was added for simple MVC widgets (with the main purpose to reduce session-state at the server).

Release 2.0.0

This release contains numerous changes which are likely to cause some porting effort for Wt 1.1.x applications to work properly.

If you are upgrading from a 1.99.x release, you will notice that some of these notes have actually evolved, especially with respect to WString and unicode support.

Here is a list of changes with respect to Wt 1.1.x that are likely to require your attention, and some tips on how to do the porting.

1) Namespace Wt

All Wt classes are now inside the namespace Wt.

To handle this change, you will need to:

2) WString

Previously, most widgets offered double methods that either used a std::string for literal text, or a WMessage for localized text.

In the new release, widgets use Wt::WString for both literal and localized text. WString offers unicode support for both literal as well as localized text. To create a literal string, simply assign or construct a Wt::WString from that string. The strings supported or both narrow and wide C and C++ strings. UTF8 encoded narrow strings may also be converted. To create a localized string, use one of the static methods WString::tr(const std::string key) and WWidget::tr(const std::string key).

To help with legacy code, WMessage is now a typedef for WString, but is deprecated and should not be used in new code. Unfortunately, the constructors WMessage(const char *text) and WMessage(const std::string text), changed meaning! While previously they took a key to construct a localized message, they now take a literal text (the exact opposite!), since they are in fact plain WString() constructors. As a consequence your application will display key values instead of resolving those values (but will not break entirely).

The new approach offers the benefit of only requiring one method signature for both literal and localizable text. This not only simplifies our work, but more importantly by using WString for displayed text in the API of your own widgets, localization (including the automatic language switching) comes automatically and is decided on by the user of your widget.

Fortunately, there is a straightforward trick to handle most consequences of this change:

3) Wide string API

Since Wt 2.0.0, the API for Wt has been changed to use WString instead of C++ narrow strings. WString supports both narrow and wide strings, and provides conversion between both. It does not provide string operations, however, and instead acts as a string container. You should convert to a C++ string type to perform operations. You should also not use WString outside of the user interface part of your application.

4) No more wmain()

Previously, the Wt library implemented the main(int argc, char **argv) function, and called a wmain() function which created the WApplication instance.

Wt 2.0.0 allows multiple applications to run within a single process. Therefore, the WApplication::exec() approach was no longer feasible. The new approach requires that:

5) Configuration in /etc/wt/wt_config.xml

Wt 2.0.0 uses a configuration file for a number of settings that could previously be configured at build time of the library, or in the API. The latter functions are:

6) Removed obsolete classes

Wt 2.0.0 removed a number of classes that were still in the widget tree, but have been obsoleted by more flexible classes:

7) Deprecate boost::regex from WRegExpValidator API

The constructor and methods that takes a boost::regex object in the WRegExpValidator API have been deprecated, to remove the dependency on boost from the public API. You should consider the std::string based construtor and method instead.

8) WObject::emit() has been removed.

Since Wt 1.99.1, we have removed WObject::emit() function. Instead, you may simply call the signal with its arguments, or use the explicit emit method (recommended).

To adapt your code, you should:

9) WResource::streamResourceData() signature has changed.

Since Wt 2.0.0, WResource::streamResourceData() returns a boolean value which indicates if all data has been streamed. If you have reimplemented WResource for your applications, you must update the signature and return true.

The change is relevant only within the new server-push support that is now in Wt 2.0.0. This allows you to continuously append to the content of a resource.

10) Rename of WJavascriptSlot to JSlot.

Release 1.1.7

This release contains lots of additions and improvements, but should be completely backwards-compatible.

Release 1.1.6

There is one change which will impact the behaviour of current applications: Currently, on exit, by default the last widget updates are shown. So, no more good-bye message. This changes slightly when one needs to redirect() to a new location: not when WApplication::exec() returns, but during the same event handling as when calling WApplication::quit().

Release 1.1.5

Nothing special...

Release 1.1.4

Changes to impact everybody, since the previous release:

Other changes: