Skip to main content

Data Binding

FD Components uses explicit dataset binding. A visual component receives an FdcDataSet, and field-oriented controls also receive a fieldName.

There is no separate form model that must be synchronized with the grid or dataset.

Bind a grid​

FdcGrid(
  dataSet: customers,
  columns: const <FdcGridColumn<dynamic>>[
    FdcIntegerColumn<dynamic>(
      fieldName: 'id',
      label: 'ID',
    ),
    FdcTextColumn<dynamic>(
      fieldName: 'company',
      label: 'Company',
    ),
    FdcBooleanColumn<dynamic>(
      fieldName: 'active',
      label: 'Active',
    ),
  ],
)

The grid reads the dataset view, follows cursor movement, participates in editing, and reacts to dataset notifications.

Bind standalone editors​

Column(
  children: <Widget>[
    FdcTextEdit(
      dataSet: customers,
      fieldName: 'company',
    ),
    FdcDecimalEdit(
      dataSet: customers,
      fieldName: 'credit_limit',
    ),
    FdcBooleanEdit(
      dataSet: customers,
      fieldName: 'active',
    ),
  ],
)

All editors are bound to the same current record.

When the dataset cursor moves, editors follow the new current record. When an edit buffer changes, other bound components observe the same dataset-owned value.

One dataset can coordinate a screen​

A typical CRUD screen can combine:

DataSet
 ├─ Grid
 ├─ Text editor
 ├─ Numeric editor
 ├─ Boolean editor
 ├─ Record navigator
 └─ Save / Cancel actions

The components do not exchange values with one another directly. They coordinate through the dataset.

This becomes particularly useful when the same data screen grows to include toolbar actions, validation messages, paging, filtering, or master-detail relationships.

Field metadata drives bound behavior​

A bound editor resolves its field definition from the dataset schema. Metadata can contribute:

  • labels;
  • required status;
  • read-only behavior;
  • data type compatibility;
  • normalization;
  • validation;
  • formatting behavior.

That keeps the schema authoritative while still allowing component-level UI configuration where needed.

Binding is record-aware​

Editors bind to the dataset current record. FD Components guards editor commit paths so that a value is not accidentally committed to a different record after navigation changes the active record.

Application code should likewise avoid caching a value from one record and later writing it back without checking whether the cursor has moved.

Use dataset APIs for programmatic writes​

Visual binding and direct code use the same data path:

customers.edit();
customers['company'] = 'Northstar Systems';
customers.post();

A grid edit or FdcTextEdit commit participates in the same dataset edit lifecycle rather than bypassing change tracking and validation.

Keep transient UI state separate​

Not every widget state belongs in the dataset. Search-field focus, panel expansion, dialog visibility, and other presentation-only state can stay in normal Flutter state management.

Use the dataset for data workflow state:

  • current record;
  • field values;
  • editing and inserting;
  • validation;
  • changes;
  • query state;
  • paging and selection APIs.

This separation keeps application architecture clear without introducing duplicate data models.

Next: Opening and Closing