Page tree

Have questions? Stuck? Please check our FAQ for some common questions and answers.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »


Tabular views, unsurprisingly, present data in a tabular form. As an example, here is a screenshot of the hosts view...

Applications can create (and inject into the GUI) their own view(s) of tabular data. This tutorial will step you through the process...

Application Set Up

Setting up the application is exactly the same as for the Custom View tutorial, with one minor difference: the choice of archetype in step (2) should be uitab instead of ui:

Currently, the uitab archetype has not been implemented, so the following command will not work until this has been fixed.


(2) Overlay the UI additional components

$ onos-create-app uitab meowster-app

Description of Template Files

The descriptions for both AppComponent and AppUiComponent remain the same as in the Custom View tutorial.


This class extends UiMessageHandler to implement code that handles events from the (client-side) sample application view. Salient features to note:

(1) implement createRequestHandlers() to provide request handler implementations for specific event types from our view.

protected Collection<RequestHandler> createRequestHandlers() {
    return ImmutableSet.of(
            new SampleDataRequestHandler(),
            new SampleDetailRequestHandler()


(2) define SampleDataRequestHandler class to handle "sampleDataRequest" events from the client. Note that this class extends TableRequestHandler, which implements most of the functionality required to support the table data model:

private static final String SAMPLE_DATA_REQ = "sampleDataRequest";
private static final String SAMPLE_DATA_RESP = "sampleDataResponse";
private static final String SAMPLES = "samples";

private final class SampleDataRequestHandler extends TableRequestHandler {
    private SampleDataRequestHandler() {

Note the call to the super-constructor, which takes three arguments:

  1. request event identifier
  2. response event identifier
  3. "root" tag for data in response payload

To simplify coding (on the client side) the following convention is used for naming these entities:

  • For a given table view, the table is identified by a "tag" (in this example, that tag is "sample")
    • request event identifier is derived as: <tag> + "DataRequest"

    • response event identifier is derived as: <tag> + "DataResponse"
    • "root" tag is derived as: <tag> + "s"


(2a) optionally override defaultColumnId():

// if necessary, override defaultColumnId() -- if it isn't "id"

Typically, table rows have a unique value (row key) to identify the row (for example, in the Devices table it is the value of the property). The default identifier for the column holding the row key is "id". If you want to use a different column identifier for the row key, your class should override defaultColumnId(). For example:

private static final String MAC = "mac";
protected String defaultColumnId() {
    return MAC;


(2b) define column identifiers:

private static final String ID = "id";
private static final String LABEL = "label";
private static final String CODE = "code";

private static final String[] COLUMN_IDS = { ID, LABEL, CODE };

protected String[] getColumnIds() {
    return COLUMN_IDS;

Note that the column identifiers defined here must match the identifiers defined in the HTML snippet for the view.


(2c) optionally override createTableModel() to provide custom cell formatters / comparators. The following example sets both a formatter and a comparator for the "code" column:

protected TableModel createTableModel() {
    TableModel tm = super.createTableModel();
    tm.setFormatter(CODE, CodeFormatter.INSTANCE);
    tm.setComparator(CODE, CodeComparator.INSTANCE);
    return tm;

See additional details about table models, formatters, and comparators.


(2d) implement populateTable() by adding rows to the supplied table model:

protected void populateTable(TableModel tm, ObjectNode payload) {
    // ...

    // fake data for demonstration purposes...
    List<Item> items = getItems();
    for (Item item: items) {
        populateRow(tm.addRow(), item);
private void populateRow(TableModel.Row row, Item item) {
            .cell(LABEL, item.label())
            .cell(CODE, item.code());

The example uses fake data for demonstration purposes. A more realistic implementation would use one or more services to obtain the required data. For example:

protected void populateTable(TableModel tm, ObjectNode payload) {
    DeviceService ds = get(DeviceService.class);
    MastershipService ms = get(MastershipService.class);
    for (Device dev : ds.getDevices()) {
        populateRow(tm.addRow(), dev, ds, ms);

private void populateRow(TableModel.Row row, Device dev,
                         DeviceService ds, MastershipService ms) {
    DeviceId id =;
    String protocol = dev.annotations().value(PROTOCOL);

    row.cell(ID, id)
        .cell(MFR, dev.manufacturer())
        .cell(HW, dev.hwVersion())
        .cell(SW, dev.swVersion())
        .cell(PROTOCOL, protocol != null ? protocol : "")
        .cell(NUM_PORTS, ds.getPorts(id).size())
        .cell(MASTER_ID, ms.getMasterFor(id));
  • No labels