This chapter describes the data-binding logic of the RecroGrid Framework List View, focusing on how a database model becomes a runtime-flexible entity that supports multiple views and behaviors, and how query results flow through to the client-side List View rendering.

Overview: List View Data-Binding Logic

List View data binding is built on the integrated model of the RecroGrid Framework:

• The database structure and relation graph are represented in the domain model through Entity Framework
• Entity configurations and their metadata are derived from the domain model and persisted in the RecroGrid Framework database
• The List View initiates a query associated with the entity’s current context, then receives the result in a runtime record structure
• The client generates columns from the received runtime-aligned record structure, based on the entity settings

Domain Model, Database, and Entity Metadata

1. Database Model and Domain Model Synchronization

The starting point is the Entity Framework model available through the DbContext. It provides a unified description of tables, fields, and navigation relations, serving as the foundation for how the RecroGrid Framework derives entities and metadata from the model. The Entity Framework model available in the DbContext provides the following inputs for the RecroGrid Framework:

• Fields, Types, Nullability, Required semantics
• Keys, Indexes, References
• Navigation properties

Based on the domain model, the RecroGrid Framework handles server-side querying and client-side List View behavior in a unified way.

2. Entity Configurations and Metadata

In the RecroGrid Framework, the concept of an entity is treated as an application capability: an entity is not merely a mapping of a table, but a descriptive unit that also includes view-relevant metadata, such as:

• Logical field set (Fields, Relation-based fields, Calculated fields)
• Default column set and order
• Filterability and sortability characteristics
• Display types and formatting recommendations
• Related entities and navigation paths

Multiple Entities for the Same Database Table

The RecroGrid Framework allows any number of entity views to be associated with database tables and their navigation relations.

1. Variants and Roles

The same underlying structure can appear as multiple entity variants:

• Different field sets
• Different relation traversal
• Different calculated and additional data
• Different behaviors and rules

This model enables the same database table to provide an optimal view representation across multiple business contexts and workflows.

2. A Single Entity Can Compose Multiple Data Sources

Entity metadata can include columns and values that do not originate directly from table columns, for example:

• Calculated values
• Aggregated, grouped, or derived fields
• Specialized relation-based extractions

Runtime Data Structure for List View Data Binding

1. Runtime-Aligned Record Structure

List View queries return a runtime-generated, metadata-aligned record structure, where each row reflects the effective entity configuration and query projection of the current context.

• The column identifier (Field name, Relation path, Calculated field name)
• The value is the cell value produced by the current query

This has the following implications for List View behavior:

• The column set is derived from the query and the current entity configuration
• Column presence is part of the runtime query context
• Client-side rendering constructs the List View representation from the received column metadata and the runtime-aligned record structure.

2. Separation of Column Definition and Row Content

The List View logic naturally separates binding into two layers:

• Column metadata: Label, Type, Formatting, Sortability, Filterability, Display behavior
• Row values: Actual values mapped to the metadata-aligned runtime record keys

This structure supports immediate rendering of the same entity with different List View configurations and different column sets.

Query Pipeline and Data Flow

1. Client-Side State and Query Parameters

On the client, the List View maintains a view state that typically includes:

• Current column set and order
• Sorting rules
• Active filter conditions
• Paging settings

This state is sent to the server in a structured format and determines the final shape of the query.

2. Server-Side Query Composition

On the server side, the RecroGrid Framework composes the query based on the domain model and entity metadata:

• Selecting the base dataset and required relation traversals
• Projecting selected fields and calculated fields
• Applying sorting and filtering rules
• Applying paging

The query result is produced in the runtime-aligned record structure.

3. Query Post-Processing and Query Override

• The system-composed query can be refined before execution, for example by adding additional conditions
• The query execution layer can be programmatically replaced with a manually composed query, provided that the resulting projection complies with the effective entity metadata and requested column set. The List View binding contract toward the client remains unchanged.

The List View request always determines the required column set, so the final query includes the requested columns. This mechanism represents a full customization level, enabling integration of specialized data sources, optimized queries, and highly specific business logic into the List View data flow.

4. Client-Side Rendering

The Blazor WebAssembly client uses the received column metadata and row dictionary to:

• Build columns
• Render values at cell level with type-specific rendering
• Apply the same binding mechanism to calculated and dynamic fields

Relation Fields in List View Binding

Relation fields act as first-class participants among List View columns:

• In the N:1 direction, fields of the related entity can appear as columns
• In the 1:N direction, related entities can appear as an embedded list in the Form view
• Multi-level relation paths are supported, with metadata controlling the traversal path
• Sorting and filtering on relation fields are processed through the same server-side query composition pipeline

The column identifier for relation fields is typically a path-like key that can be referenced consistently in the runtime-aligned record structure.

Extended and Calculated Fields

List View data binding naturally supports fields produced during runtime query execution:

• These fields are part of the server-side query projection and are translated to database-level expressions
• Calculated fields expressing business-level values
• Aggregated or consolidated values
• Fields created for specialized presentation purposes

Dynamic Columns Generated at Runtime

These columns are generated after the database query has been executed, during server-side post-processing. They are computed per record in managed code and are not part of the database-level projection.

• These columns represent values computed after the database-level projection, based on the query result
• Column metadata can be defined similarly to other properties (Type, Label, Formatting, Display behavior, Interactions)
• External or system-provided context data
• The dynamic columns are generated by invoking custom server-side logic after the database query has executed.

Configuration Level and Code-Level Customization

The RecroGrid Framework builds the List View based on entity metadata, so a single database table can appear through multiple entity variants optimized for different business work contexts. Entity variants describe presentation, interactions, and query context in a unified way, enabling the same underlying data to be used in multiple List View representations with different column sets and behaviors.

• Different column sets and default order
• Different relation paths and traversal depth
• Different calculated and extended fields
• Different List View behaviors and rules (Filters, Sorting, Display recommendations)
• Different Tree and Form views
• Different permission levels

Next step