EEZ Studio Tabulator Row Events: Do Not Mistake index or position for a Business Key

An EEZ Studio Tabulator row-selection event does not automatically carry the selected record's application identifier. The pinned adapter creates an object containing index and position. Those fields come from table internals and a row-position method, respectively; neither field is populated from an application's business-key column.

The Tabulator widget documentation describes the table integration. The exact event conversion is visible in TABULATOR_EVENTS in the pinned adapter source, EEZ Studio v0.29.0 commit 3000161d09d40a5c1dc2477ddc30b38037b3a612.

This distinction matters when selecting a row initiates work on a record. A number named index can look authoritative while representing a different kind of identity from the one the operation requires.

Read the two expressions literally

For ON_ROW_SELECTED and ON_ROW_DESELECTED, the adapter calculates index by searching row.getTable().rowManager.rows for row._row. It calculates position by calling row.getPosition(). The resulting event object contains those two properties.

The first expression uses an internal row collection and the private-looking _row member. It is not a lookup of a user-defined id field, nor is it the same expression as a library row-key accessor. The second is a library method whose positional semantics must be checked against the installed Tabulator version and current view.

Do not assume the fields share the same numbering base or respond identically to sorting and filtering. The EEZ conversion itself does not explain every upstream positional rule. It does, however, establish that the two values have different origins.

Test the mapping instead of guessing from the first row

Create a proposed fixture containing records with conspicuous keys, such as REC-A, REC-B and REC-C, and a separate numeric measurement column. Log both event fields when selecting each row. Record which record is visibly selected and the table data in effect at that moment.

Then sort by the measurement column, filter out one record and repeat. A first-row-only test on the original order cannot distinguish an internal index, a displayed position and a coincidentally similar application key.

The purpose is not to assert in advance that every operation changes both values. It is to determine which mapping the installed adapter actually exposes. Include deselection in the fixture because the pinned source applies the same conversion there.

If the application reloads the dataset, test the event-to-record mapping across that operation separately. An index saved before replacement cannot establish which record occupies a later dataset's corresponding slot.

Resolve the record at one explicit boundary

The event object shown here does not include row data. A Flow handler should therefore not pretend that index already is the record's identifier. Establish a supported way to resolve the event against the relevant table state, or adapt the integration to pass the actual application key explicitly.

Simply indexing the original input array with index is justified only after verifying that the table's internal row collection has the same membership and ordering for the supported operations. Sorting, filtering, data replacement and table editing are reasons to investigate that assumption, not reasons to declare a particular mismatch without evidence.

Where an integration change is required, keep it small: obtain the selected row's data through the installed library's supported API and emit the needed key in a documented event contract. That is a proposed adapter design, not a feature claimed to exist in the inspected EEZ event payload.

For consequential operations, resolve and display the intended record before acting. A readable caption alone cannot compensate for an unresolved index-to-record mapping.

Preserve the adapter boundary across upgrades

The use of rowManager.rows and _row makes this conversion particularly worth reviewing when the bundled table library changes. Passing a basic selection test does not prove those internal objects retain identical meanings in another release.

Keep a compact fixture showing selected record, both payload fields and the resolved application key for the operations the product supports. No table was executed here. The source-backed result is the provenance of the two event fields, which gives that fixture a concrete purpose beyond checking whether row highlighting still works.