Built-in Selection Providers

SolidX ships with two built-in dynamic selection providers so you can wire up common dropdown patterns without writing any code. If you need something more advanced, see Dynamic Selection Providers for creating your own.

Provider	Use case
ListOfValuesSelectionProvider	Populate a dropdown from List of Values metadata entries
PseudoForeignKeySelectionProvider	Populate a dropdown from records in any existing model, creating a lightweight foreign-key-style relationship without a formal database relation

---

ListOfValuesSelectionProvider

Use this provider when the options for a field come from your List of Values metadata. It filters LOV entries by type and maps each entry's display to the label and value to the stored value.

Context

The context object passed via selectionDynamicProviderCtxt accepts:

Key	Type	Required	Description
type	string	Yes	The LOV type to filter by (e.g. "REGULATED_BY", "INDUSTRY")

Field Metadata Example

Example: Dynamic selection field using ListOfValuesSelectionProvider

{
  "name": "regulatedBy",
  "displayName": "Regulated By",
  "description": "Regulated By",
  "type": "selectionDynamic",
  "ormType": "varchar",
  "isSystem": false,
  "selectionDynamicProvider": "ListOfValuesSelectionProvider",
  "selectionDynamicProviderCtxt": "{\"type\": \"REGULATED_BY\"}",
  "selectionValueType": "string",
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "encrypt": false,
  "isUserKey": false,
  "enableAuditTracking": true,
  "isMultiSelect": true
}

How It Works

1. SolidX reads the selectionDynamicProviderCtxt and extracts the type value.
2. The provider queries the internal ListOfValuesService with a filter of type = <your type>.
3. If the user types a search query in the dropdown, the provider additionally filters by display (case-insensitive contains).
4. Each matching LOV record is mapped to { label: record.display, value: record.value } and returned to the UI.

Info

The LOV entries themselves are defined in your module's metadata file under the key listOfValues key. See the List of Values metadata schema for details on how to define them.

You can also refer to Configuring List of Values for instructions on how to manage LOV entries via the admin UI.

---

PseudoForeignKeySelectionProvider

Use this provider when you want a dropdown whose options come from records in another model — without creating a formal database foreign key relationship. This is useful for loosely-coupled references where a full relation is overkill or the models live in different modules.

Info

Use PseudoForeignKeySelectionProvider when you need to link data from a co-model (or any other model) to your current model but you cannot or don't want to create an actual database relation between them.

Example scenario: Suppose you have a customer model in one module and a country model in another. You want the user to pick a country when creating a customer, but you don't want a formal foreign key — perhaps because the models are managed by different teams, the country data is reference-only, or you simply want to store the country code as a plain string rather than enforce referential integrity. With this provider you can populate a dynamic dropdown from the country model's records while keeping the two models completely decoupled at the database level.

Context

The context object passed via selectionDynamicProviderCtxt accepts:

Key	Type	Required	Description
modelName	string	Yes	The name of the model to query (e.g. "country")
labelFieldName	string	Yes	The field on the target model to use as the display label
valueFieldName	string	Yes	The field on the target model to use as the stored value
whereClauseFields	string[]	Yes	Fields on the target model to search against when the user types a query

Note

• The provider also respects the standard limit and offset context properties for pagination.

Field Metadata Example

Example: Dynamic selection field using PseudoForeignKeySelectionProvider

{
  "name": "countryOfIncorporation",
  "displayName": "Country of Incorporation",
  "description": "Select the country of incorporation",
  "type": "selectionDynamic",
  "ormType": "varchar",
  "isSystem": false,
  "selectionDynamicProvider": "PseudoForeignKeySelectionProvider",
  "selectionDynamicProviderCtxt": "{\"modelName\": \"country\", \"labelFieldName\": \"countryName\", \"valueFieldName\": \"countryCode\", \"whereClauseFields\": [\"countryName\", \"countryCode\"]}",
  "selectionValueType": "string",
  "required": true,
  "unique": false,
  "index": false,
  "private": false,
  "encrypt": false,
  "isUserKey": false,
  "enableAuditTracking": true,
  "isMultiSelect": false
}

How It Works

1. SolidX reads the selectionDynamicProviderCtxt and extracts modelName, labelFieldName, valueFieldName, and whereClauseFields.
2. The provider uses SolidIntrospectService to look up the CRUD service for the specified model at runtime.
3. If the user types a search query, the provider builds an $or filter across all whereClauseFields using case-insensitive contains ($containsi).
4. The matching records are mapped to { label: record[labelFieldName], value: record[valueFieldName] } and returned to the UI.

When to use which?

• Use ListOfValuesSelectionProvider when your options are a fixed, admin-managed set defined in metadata (e.g. statuses, categories, industries).
• Use PseudoForeignKeySelectionProvider when your options come from live records in another model (e.g. countries, clients, products).
• If neither fits, create a custom dynamic selection provider.