Skip to content

Fields, expressions, and validation

Client keyword reference / Fields, expressions, and validation

IFS Cloud 26R1 · Documentation-based examples · Not compiled or executed in IFS.

Begin with the page scaffold. Add the named attributes to your projection contract before inserting snippets into a group or list. Match types and nullability; a client field does not create a database column.

  1. Expose Title (Text, at least 80 characters) and Closed (Boolean).
  2. Replace the title field inside RequestSummary with this block.
  3. Test a blank title, an 80-character value, an overlength value, and a closed record.
  4. Repeat invalid writes through the authorized API test route: the server must enforce business rules too.
field Title {
label = "Request summary";
maxlength = 80;
size = Large;
required = [true];
editable = [Closed = false];
visible = [true];
validate command {
execute {
if [Title = null] {
error("Enter a summary before continuing.");
}
}
}
}

Bracketed conditions are client expressions, not JavaScript or SQL. = compares inside the condition; do not substitute JavaScript ===. A null Closed needs an explicit policy instead of assuming it means false. Hiding or disabling a field is presentation behavior, not an access-control boundary.

Use an immutable display for the identifier and a multiline editor for Notes (Text/LongText compatible with the target model). Boolean rendering follows the attribute’s type and nullability; a text value containing TRUE is not automatically a Boolean.

static RequestId;
field Notes {
label = "Investigation notes";
multiline = true;
height = Medium;
}
field Closed {
label = "Completion";
truelabel = "Closed";
falselabel = "Open";
}

Enter two lines, save, reload, and compare line breaks. Test false, true, and null if allowed. Note that multiline = true is a literal property here, while editable = [true] is an expression: brackets are not universally interchangeable.

Expose EstimateHours and HourlyRate as numbers and add this inside a list. The estimate is a display calculation, not an authoritative stored charge.

computedfield EstimatedCost {
label = "Indicative labor cost";
value = "#{EstimateHours * HourlyRate}";
}

With 3 hours and a rate of 40, expect 120. Test zero and missing operands before deciding how to present unavailable estimates. ${Title} interpolates text; #{...} evaluates a computed expression. Do not silently assume a display total covers records that were not loaded, or use it instead of server-side financial calculation.

  1. Expose PlannedFrom and PlannedUntil as Date attributes.
  2. Insert the range block into a group; use a separate field for a timestamp such as ReceivedAt.
  3. Test the same day, an end before the start, and a blank endpoint. Enforce the permitted range on the server.
daterangefield {
label = "Planned service window";
startdate PlannedFrom;
enddate PlannedUntil;
}
field PlannedUntil {
basedate = PlannedFrom;
}

The second block is an alternative single-field presentation; do not add both editors for the same attribute without a reason. basedate guides the picker and does not enforce end-after-start. A Time field may use format = longtime;. showonlydate = [true]; hides time in presentation; it does not change a Timestamp to a Date. See time-zone semantics before applying that display choice.

Use a generated enumeration attribute Priority, a numeric QualityScore, and a supported color attribute BoardColor. Add each control separately and build between changes.

radiogroup Priority {
label = "Dispatch priority";
editable = [true];
}
field QualityScore {
rating {
maxrating = 4;
showlabel = true;
}
}
field BoardColor {
colorpicker {
defaultemphasis Colorpicker2 = [true];
editmode = [true];
}
}

Check all enumeration choices, scores at 0 and 4, and the stored value after changing color. Reject scores above the allowed maximum at the service layer. editmode is control-specific; this color-picker expression is not a page edit-mode enum.

Use the build and acceptance checklist before delivering a change.