The event management System has been completely refactored. The old pattern based on event listeners was actually not helpful in practice and something had to be done to improve this.

The new system uses one event manager per event type, it is no longer needed to load all the event types as it was the case with a single central event manager.

Events are now handled by event handler method registered on the proper event manager in the widget instance, *Adapter classes are not needed anymore.

Basically, each Widget instance defines its own set of event managers to which event handler methods are registered as in the following example:

var myButton = new zwt.ui.Button();
myButton.setText("Click me!");

myButton.getClickEventManager().addClickHandler(function(zwt_ui_Button_button, zwt_event_ClickEvent_event) {
    alert("You've just clicked me!");
});

This new approach removes the need to generate *Listeners.js files used to define event listeners classes and register them to the Widgets. As a result only the Part, the Model and the Controller (with the Controller_callback) are generated when compiling ZUIDL files. This greatly reduces the footprint and the readability of the code.

Another big advantage of this pattern lays in the fact that it can be applied to any component interested in event processing, it is not specific to widgets as you can see in the following class diagram.

The focus management had to be reviewed after this event management refactoring. In previous releases, a focus events could only be handled on some specific Widgets (like the TextField Widget) but in practice every Widget can emit focus event. In this new release a FocusEventManager is provided to all the widgets in the zwt.ui.Widget class.

Keyboard events are tightly coupled to the focus events. Indeed when a widget has the focus all the keyboard events should be redirected to this widget and finally the Window. In order to do that, the zwt.ui.Widget class now provides a KeyboardEventManager and the window is responsible to first route the keyboard events to the current focused widget before processing them.

The same remark applies to the wheel events and therefore a WheelEventManager is also provided to every widgets.

Until now the layout was calculated based on the dimension of the parent container which made impossible to have a component that grows with its content.

To have a better idea of the issue just consider a list of items where each item has a fixed height and width, if you add or remove an item you may expect the list to adjust its size to the number of items it contains just as it does with a standard HTML list.

The layout management system now considers the dimension of the parent container to decide how to calculate the layout and how much space is available for the content. For instance, the fill property may be overridden by a container depending on the container dimension whether it is fixed (a width and/or a height value is set) or elastic (no width and/or no height value is set). In the first case the content is resized to fit in the container's dimension, in the second case the intrinsic content dimension is used and the container is resized to fit the content's dimension.

When the intrinsic content dimension is modified (label change, new item in a list...), the parent container is notified through a zwt.ui.container.ContentEvent and it can then determine how to redraw the layout. As a result it is no longer required to call draw or redraw methods explicitly when some content is modified or when widgets are added to or removed from a container.

In addition to the API changes resulting from some Widgets refactoring, some other modifications have been done in order to harmonize the naming and the behavior of the methods across the framework.

All the legacy code related to IE6 support has been removed. The framework does no longer support IE6 (too bad...).

The ViewModel pattern already used in the table widget has proven to be very convenient to control the data displayed in a complex widget. In this new release list and tree Widgets have been completely redesigned to benefits from this pattern.

The tab bar widget now supports tab overflow when the items don't fit in the space allocated to the tab bar.

It is also possible to make tab items closable.

The stack panel has been refactored to use a vertical panel to display items. This comes with some drawbacks especially when the stack panel is animated but the benefits brought by the use of vertical panel are huge: scrolling, elastic layout... Thanks to this, it is now also possible to open multiple stack at a time.

This simple new panel displays widgets inline using their intrinsic dimension.

The new TemplateView widget can be used to display data formatted by template. The default implementation is based on XSL but the API has been designed to support other implementations as well.

The default theme has been updated to be more productive and more modern.

The JS API documentation is now generated using JSDoc-toolkit. This will let us create a Zeleos template to efficiently present code documentation in future releases.