Create Qt-based model of tiled catalog

[prjemian]

To view the results of the catalog filter (search) terms, we need to create a model (such as QtCore.QAbstractTableModel) of the search results. The QtWidgets.QTableView widget displays the table in the GUI.

[prjemian]

See this example of a QAbstractTableModel/QTableView pair.

[prjemian]

When subclassing QAbstractTableModel , you must implement rowCount() , columnCount() , and data() .

It is not necessary to copy data from the search results into a new table. Instead, our TiledBlueskyRunsTableModel would access the necessary content from the tiled search results object from within the model's methods.

In the example, self.datatable (a local addition for the example) might be our search results object which is (re)created by the update() method whenever the search terms change. (But this update() method is part of this specific example and not a method from QAbstractItemModel().) We won't need to create an update() method in our TiledBlueskyRunsTableModel() class unless we want to create a Qt slot which would be called from some other part of the user interface. (summary: It is probably a good idea to create this method.)

The rowCount() method would return the number of runs to be displayed. There may be more in the catalog but we might to create some sort of pager to display the catalog in pages of no more than 10, 20, 50, 100, ... runs at a time.

The columnCount() method would return the number of different parameters (start date/time, scan_id, plan_name, ...) we choose to display for any run.

The data() method would return a string representation of whatever is in the cell at the table's specified row and column. Row is an integer from 0 to len(rows)-1. This would index into the corresponding key (the uid) of the results object. The column is another integer that indexes into the list of parameters we choose to display.

[prjemian]

Since the tiled server can return different kinds of catalog (files, bluesky runs, something else), we must identify that any selected catalog has the type of content that is expected (bluesky runs).

Here are a couple examples of catalogs served by my local tiled server, as discovered using this URIhttp://TILED_SERVER_NAME:TILED_SERVER_PORT/api/v1/node/metadata/CATALOG_NAME

bluesky runs

{"data":{"id":"training","attributes":{"ancestors":[],"structure_family":"node","specs":[{"name":"CatalogOfBlueskyRuns","version":"1"}],"metadata":{},"structure":{"contents":null,"count":8766},"sorting":[{"key":"time","direction":1}],"references":[]},"links":{"self":"http://192.168.144.97:8000/api/v1/node/metadata/training","search":"http://192.168.144.97:8000/api/v1/node/search/training","full":"http://192.168.144.97:8000/api/v1/node/full/training"},"meta":null},"error":null,"links":null,"meta":{}}

file directory

{"data":{"id":"files","attributes":{"ancestors":[],"structure_family":"node","specs":[],"metadata":{},"structure":{"contents":null,"count":4},"sorting":[{"key":"_","direction":1}],"references":[]},"links":{"self":"http://192.168.144.97:8000/api/v1/node/metadata/files","search":"http://192.168.144.97:8000/api/v1/node/search/files","full":"http://192.168.144.97:8000/api/v1/node/full/files"},"meta":null},"error":null,"links":null,"meta":{}}

Note

Note the specs key in the JSON. We are looking for catalogs with "name":"CatalogOfBlueskyRuns". Other catalogs won't have the various search terms we are expecting. Even more, the keys of other catalogs are not expected to be the uid of bluesky runs. For now, we should not try to handle catalogs that are not bluesky runs.

[prjemian]

BTW, in the JSON, the id key is the name of the catalog. It is just an identifier and carries no additional meaning. (Can't use the id to determine if a catalog contains bluesky runs.)

[prjemian]

We'll need to learn how to get the type of catalog from the tiled.client interface. The example above shows how to get it with a URI GET request.