feat: server-side JS field validators for extended inputs (#158)

[romain-pm]

What

Completes the server-side validation gap left open in #158: the extended field types now re-enforce their constraints on submission, in JavaScript, so a client that bypasses the browser cannot store out-of-range values.

Stacked on #162 (base branch feat/extended-inputs-module) — review/merge that first. The diff here is only the validation layer.

Cross-repo dependency ⚠️

Depends on a new javascript-modules SDK: Jahia/javascript-modules#686 (branch feature/js-server-extensions-sdk, stacked on feature/js-server-extensions). That branch exports a small, polyglot-free SDK (JSServerExtensionInvoker) so a third-party bundle can consume JS-declared server extensions and invoke their callbacks. That must be released before this can build/run against a stock engine.

How it works

1. js-modules SDK — JSServerExtensionInvoker.forEach(type, handler) runs within one pooled GraalVM context; Invoker.call(callable, args…) executes a JS function and converts the result to plain Java. No GraalVM/engine-internal types leak, so formidable-engine needs no polyglot dependency.
2. formidable-engine — a new validateFieldsWithJs pipeline step (after validateRequired) loads each submitted field's node with a system session and runs the JS validators registered for its node type; a violation rejects the submission with FMDB-010. Fails closed on validator error; skipped entirely (graceful) if the SDK service is absent. FormFieldMetadataCollector now carries field node identifiers; JsFieldValidator is the bridge.
3. formidable-extended-inputs — registerFormFieldValidator({ nodeType }, (node, value, locale) => …) (thin wrapper over server.registry.add), plus validators for rating (1..max integer), scale (min..max by step), switch (true/false), consent (true, required-aware).

registerFormFieldValidator({ nodeType: "fmdbext:rating" }, (node, value) => {
  const max = clamp(intProp(node, "maxValue", 5), 2, 10);
  const n = Number(value);
  if (!Number.isInteger(n) || n < 1 || n > max) return { message: `Rating must be 1..${max}.` };
});

Verification

Built, deployed (SDK engine + formidable) and driven end-to-end on a local Jahia 8.2.x by POSTing directly to /modules/formidable-engine/form-submit, bypassing the browser:

Case	Result
Valid (incl. edges: rating 5, scale min, nps 0, switch false)	✅ accepted
rating 999, abc, 0, 3.5	⛔ FMDB-010
scale (effort) 99, abc	⛔ FMDB-010
switch maybe	⛔ FMDB-010
consent yes	⛔ FMDB-010
nps 11, -1	⛔ FMDB-010

149 formidable-engine unit tests pass, and 19 new Cypress e2e specs (see below) pass against a local instance.

Notes / follow-ups

• This is the recommended "option 1" from the Request: additional field types (rating, consent, switch, scale/NPS) #158 discussion (a Formidable-owned submission-pipeline JS hook) — it keeps formidable-extended-inputs pure-JS/CND with no per-field Java.
• The scale validator reads the node's own min/max/step; a scale rendered via the nps view but configured with custom bounds would validate against those bounds (documented edge case).
• Cypress server-rejection specs included (security/42-extended-inputs-server-validation.cy.ts, 19 tests: valid + boundary accepted, forged rating/scale/switch/consent — incl. an off-step scale value — rejected with FMDB-010); formidable-extended-inputs added to the CI provisioning manifest. Messages are literal English (surfaced only as the opaque FMDB-010 code to visitors); {bundle.key} i18n could be wired if we want localized validator messages in logs.
• SDK import is declared version-less (SNAPSHOT); pin once the js-modules SDK is released.

[github-actions]

📝 Documentation Guidelines

Thank you for contributing to our documentation! To ensure your contributions meet our standards, please review these resources:

• How to push markdown documents to the Academy - Learn the process for publishing documentation
• Documentation style guide and writing guidelines - Follow our style conventions

This comment is posted automatically when changes are detected in the docs/ folder.

[hduchesne]

Heads-up: the base branch of this PR (feat/extended-inputs-module, #162) was absorbed into #172 and closed as superseded, so this PR will need a retarget/rebase onto main once #172 merges.

A few things to know for that rebase — #172 also addressed the server-side validation gap, but at a different level:

• Generic mixin-driven Java validation landed in FieldValidator: fields carrying fmdbmix:numberField must submit a finite number within their declared minValue/maxValue, and fmdbmix:booleanField fields must submit exactly "true"/"false" (the four extended fields now carry these mixins). It is deliberately generic per value kind — it does not check rating integer-ness, scale step, or consent must-be-true, which your JS validators cover.
• The two layers look complementary rather than competing: the engine-side check is a zero-dependency baseline that works today, while this PR's registerFormFieldValidator seam adds per-type precision and lets a pure-JS module contribute validators — and it remains gated on the js-modules SDK release (feat: JSServerExtensionInvoker SDK — consume JS-declared server extensions from other bundles javascript-modules#686). My suggestion would be to keep both (defense in depth), but that's a team call.
• Expected conflicts when rebasing: FormFieldMetadataCollector (feat: extensible conditional-logic framework — mixin-driven sources, fieldKey identity, jsVariable rules, extended inputs #172 adds the number/boolean flags and minNumber/maxNumber constraints there), the CI provisioning manifest (both PRs add formidable-extended-inputs), and nothing on the Cypress side (your security/42 spec coexists with feat: extensible conditional-logic framework — mixin-driven sources, fieldKey identity, jsVariable rules, extended inputs #172's fields/212-215).

Also note #172 shipped a few fixes on the fields your validators target (switch buttons mode no longer prechecks "No", rating DOM order) — none of them change the submitted value contract, so your validator logic should rebase cleanly.

[hduchesne]

Branch housekeeping: this draft is more than a hundred commits behind main since July. Do you plan to pick it up (a rebase would be the first step), or can we close it and keep the work reachable from the closed PR? No action from me until you say.