A tree list is constructed by combining several tree node objects in a tree
hierarchy, by passing the parent tree node as the last argument in the child
node constructor, or by using addChildNode(), to add a child to its parent.

Each tree node has a label, and optionally a label icon pair. The icon pair
offers the capability to show a different icon depending on the state of the
node (expanded or collapsed). When the node has any children, a child count
may be displayed next to the label using
setChildCountPolicy().

Expanding a tree node it will collapse all its children, so that a user may
collapse/expand a node as a short-cut to collapsing all children.

The treenode provides several policies to communicate the current contents of
the tree to the client (if possible):

WTreeNode.LoadPolicy.LazyLoading: only the minimum is transmitted to
the client. When expanding a node for the first time, only then it is
transmitted to the client, and this may thus have some latency.

WTreeNode.LoadPolicy.NextLevelLoading: all leafs of visible children
are transmitted, but not their children. This provides a good trade-off
between bandwith use and interactivity, since expanding any tree node will
happen instantly, and at the same time trigger some communication in the
back-ground to load the next level of invisible nodes.

There are a few scenarios where it makes sense to specialize the WTreeNode
class. One scenario is create a tree that is populated dynamically while
browsing. For this purpose you should reimplement the
populate() method, whose default implementation
does nothing. This method is called when 'loading' the node. The
exact moment for loading a treenode depends on the LoadPolicy.

A second scenario that is if you want to customize the look of the tree label
(see getLabelArea()) or if you want to
modify or augment the event collapse/expand event handling (see
doExpand() and doCollapse()).