The NatTable is a custom painted table widget that doesn't use default SWT composites for rendering (with some exceptions on editing or dialogs). As only those elements are calculated and rendered that are visible to the user, you can speak of the NatTable as a virtual table. This enables it to handle huge amounts of data without performance loss on rendering or creating TableItem objects, like a non-virtual SWT table would do.

A layer is NatTable's way of adding functionality. Each feature usually is implemented by a separate layer. For example column hiding is implemented by the ColumnHideShow layer, Sorting is implemented by the SortHeaderLayer and so on. Layers can be arranged in 'stacks', by piling them on top of each other. At the bottom of each layer stack there should be a DataLayer which serves as a data source for all other layers.

For a list of available layers you can have a look here.

The above diagram shows the architecture of a NatTable that is build as a grid with several layers.

If you want to implement a grid with column and row headers like in the diagram above, you should use the GridLayer. By doing this the NatTable is splitted into regions which makes it easier to manage the different areas in configuration for example. Additionally to the regions showed in the diagram there are regions for column and row header groups and the filter row.

For every NatTable instance the configuration information is held in the following registries:

• ConfigRegistry
• UiBindingRegistry

Every layer has configuration information associated with it. This is in the form of IConfiguration objects. When the NatTable starts up every layer is given the opportunity to configure itself and make entries in the ConfigRegistry and the UiBindingRegistry. Mainly the following aspects are affected by configuration:

• Styling
• Editing
• UI Bindings

The above simplified UML diagram shows the relationship regarding configuration on the NatTable and its layers.

For handling user interaction with the NatTable, actions of type IKeyAction, IMouseAction or IDragMode can be registered on UI interactions (see here). Normally these actions will then fire a Command on the NatTable to invoke some behaviour. Commands are passed down the layer stack until a layer handles the Command and stops further propagation. A layer can handle a Command by special handling within the layer itself or on registering the corresponding command handler to the layer. Executing actions on the NatTable programmatically is also achieved by firing Commands on the NatTable.

After a Command is executed, normally the state and therefore the UI needs to refreshed or at least the layers need to be informed about the changed state. For this an event mechanism is used within the NatTable. Typically once a command is handled by a layer, the layer will fire an event to indicate that a change has occurred. Anyone can register themselves as a listener to layer events by implementing the ILayerListener interface.

Note that commands travel down the layer stack and normally will be consumed on handling, while events travel up the layer stack informing every listener whether handled or not.

For further information have a look here.