Conditional Show/Hide/Disable Logic
Four related methods react to a field's value - two are form-only client-side UX, two are grid-level and server-enforced.
condition() - live form UX
->condition($watchField, $operator, $value, $targetField, $effect) shows, hides, enables, or disables $targetField based on $watchField's CURRENT value in the OPEN FORM, re-checked live as the visitor types/selects.
$xcrud->condition('status', 'eq', 'inactive', 'reason', 'show');| Parameter | Type | Default | Description |
|---|---|---|---|
$watchField | string | - | Field whose live value drives the condition |
$operator | string | - | Symbol (=, !=, >, >=, <, <=) or code (eq, neq, gt, gte, lt, lte, contains, starts, ends) |
$value | string | - | Value compared against $watchField |
$targetField | string | - | Field the effect is applied to |
$effect | string | - | show, hide, enable, or disable |
Purely a client-side UX convenience: the API has no idea these rules exist, so a disabled/hidden target field is not thereby protected from being submitted some other way.
disable_logic() - server-evaluated, edit form only
->disable_logic($fields, $condition) disables field(s) in the EDIT form whenever $condition evaluates true against the row currently being edited. $condition is either a plain "field OP value" comparison evaluated in PHP, or a {{...}} raw SQL fragment for anything a plain comparison can't express.
$xcrud->disable_logic('total', 'total>1000');
$xcrud->disable_logic(['total', 'checkNo'], '{{IN (SELECT amount FROM payments LIMIT 1)}}');Never applies to a brand-new record (the Add form) - there's no row yet for a condition to evaluate against.
hide_logic() - server-evaluated, LIST view only
->hide_logic($fields, $condition) uses the same condition grammar as disable_logic(), but for the LIST view: whenever $condition evaluates true for a row, that row's value for $fields is blanked outright (null) before the response is ever built. This is a real, server-side hide - nothing sensitive rides along in the JSON for a visitor to read out of devtools, unlike a value that's merely styled/hidden client-side.
$xcrud->hide_logic('total', '{{IN (SELECT amount FROM payments LIMIT 1)}}');logic() - the unified superset
->logic($fields, $condition, $action = 'hide', $content = null) is a single, more general entry point over disable_logic()/hide_logic(), picking which behavior applies via $action. Unlike a bare hide_logic() blank, 'hide' can substitute custom HTML content in place of the blanked cell.
$xcrud->logic('paymentDate', 'amount>50000', 'hide', '<span class="text-red-600 font-bold">High Value</span>');
$xcrud->logic('checkNumber', 'amount>50000', 'disable');| Parameter | Type | Default | Description |
|---|---|---|---|
$fields | string|array | - | Field(s) the action applies to |
$condition | string | - | Plain comparison or a {{sql}} expression |
$action | string | 'hide' | 'hide' (LIST view) or 'disable' (edit form) |
$content | ?string | null | Only used by 'hide': HTML shown in place of a blank cell |
The key distinction
condition() is form-only, client-side UX - it changes what's visible/enabled in the open form for a nicer experience, but enforces nothing. hide_logic()/logic('hide', ...) are LIST-view and genuinely server-enforced - the value never reaches the client at all when the condition matches. Reach for condition() to guide data entry; reach for hide_logic()/logic() when a value must actually not leave the server for some rows.