Runtime packages
한국어. Implementation and verification are recorded in feature status.
Required capabilities
- CURP-001 Every implementation (JavaScript/TypeScript, PHP library, PHP native extension, Go, Rust and Python) provides composition and expressions, form compilation and binding, form HTML, list and detail rendering, and validation.
A server language can render forms without starting a JavaScript server or invoking another language's executable.
This item defines a requirement, not completed implementation. The PHP extension may share compiled libraries, but both operations execute inside the PHP process. PHP packages and the extension implement the same public classes. An enabled extension registers those classes before any script runs; otherwise, Composer autoloads the PHP implementation. The PHP API contract defines loading and method equality. Comparison tests run PHP and native PHP in separate processes and verify which implementation actually executed. An unavailable native module fails the native test target.
API operations
Names use each language's naming convention. The operations and results remain the same; no runtime selector is embedded in a field specification.
- CURP-006 Compile structure — JavaScript:
compileForm; PHP library:Generator::compileForm; Go:CompileForm; Rust:compile_form; PHP native:Generator::compileForm - CURP-007 Bind data — JavaScript:
bindForm; PHP library:Generator::bindForm; Go:BindForm; Rust:bind_form; PHP native:Generator::bindForm - CURP-008 Bind buttons — JavaScript:
bindButtons; PHP library:Generator::bindButtons; Go:BindButtons; Rust:bind_buttons; PHP native:Generator::bindButtons - CURP-009 Render buttons — JavaScript:
formButtonsHtml; PHP library:Generator::formButtonsHtml; Go:FormButtonsHTML; Rust:form_buttons_html; PHP native:Generator::formButtonsHtml - CURP-010 Create instance — JavaScript:
createForm; PHP library:new Form; Go:NewForm; Rust:Form::new; PHP native:new Form - CURP-011 Replace data — JavaScript:
setData; PHP library:$form->setData; Go:SetData; Rust:set_data; PHP native:$form->setData - CURP-012 Read data — JavaScript:
getData; PHP library:$form->getData; Go:GetData; Rust:get_data; PHP native:$form->getData - CURP-013 Render form — JavaScript:
renderForm; PHP library:Generator::renderForm; Go:RenderForm; Rust:render_form; PHP native:Generator::renderForm - CURP-014 Build list — JavaScript:
buildList; PHP library:Generator::buildList; Go:BuildList; Rust:build_list; PHP native:Generator::buildList - CURP-015 Render list — JavaScript:
renderList; PHP library:Generator::renderList; Go:RenderList; Rust:render_list; PHP native:Generator::renderList - CURP-016 Build detail — JavaScript:
buildDetail; PHP library:Generator::buildDetail; Go:BuildDetail; Rust:build_detail; PHP native:Generator::buildDetail - CURP-017 Render detail — JavaScript:
renderDetail; PHP library:Generator::renderDetail; Go:RenderDetail; Rust:render_detail; PHP native:Generator::renderDetail - CURP-018 Validate — JavaScript:
validate; PHP library:Validator::validate; Go:Validate; Rust:validate; PHP native:Validator::validate
Every runtime builds the same detail model and writes the same detail HTML. The
shared detail fixture is compared at both
levels in JavaScript, the HTML renderer, the PHP library, Go, Rust and the PHP extension:
the buildDetail model with its member order, and the renderDetail HTML byte for byte
with React's server rendering.
Both PHP implementations use the classes Polyspec\Crudui\Generator,
Polyspec\Crudui\Validator and Polyspec\Crudui\Form. The
PHP API contract defines the common methods and
loading order. The extension registers these classes when enabled. Without the
extension, Composer autoloads the PHP classes. Examples use the same calls in
both configurations; comparison tests use separate PHP processes and verify
class provenance and method signatures.
Shared contracts and separate responsibilities
All runtimes implement the same schema, expressions, validation rules, form runtime and input text rules. Within each runtime, generation and validation reuse composition and expression evaluation. Rendering does not redefine requiredness or validation rules.
- CURP-019 Compilation resolves references and prepares the complete form structure without record data. The output can be serialized and cached.
- CURP-020 An instance owns record values, defaults, row identities and row operations. Instances do not modify shared templates.
- CURP-021 Binding evaluates field values, localization and design against instance data.
- CURP-022 Rendering creates HTML from evaluated fields. Validation receives submitted record data and reports validation or specification errors.
The browser binding, which applies user input and row actions, is documented in the form binding package.
Server rendering and static delivery are both supported. Rendering can use data on the server, or load a cached structure in the browser and inject data later. Neither configuration changes the schema, record structure or validation rules.
Data and interoperability
- CURP-024 Compiled templates share one JSON contract across runtimes. A template compiled by one runtime can be bound by another without modification. Template field order and keyed record order are preserved. An unordered host-language map cannot be used to infer a lost declaration or row order.
- CURP-025 The ordered JSON procedure defines transport
verification. Ordered JSON object members become ordered runtime objects;
arrays remain arrays. Absent values,
null, empty objects and empty arrays remain distinct. Runtime conversion does not introduce identity or ordering fields. - CURP-026 Each implementation maps the form value model to the native types of its
language and back without losing the difference between an empty object and an empty array,
between a missing member and
null, the order of object members or the type of a scalar. Where the language has one type for both an array and an object, such as a PHP array, the caller states which it is, and a value that no native type can carry exactly fails explicitly. - CURP-027 Repeated row keys identify rows within their parent collection. Saved sequences, new keys, ordering and scoped row operations follow the form runtime contract in every implementation. Invalid operations leave both data and evaluated fields unchanged.
Implementation packages
The TypeScript implementation consists of the generator core
(@polyspec/crudui-generator-core, packages/generator/ts), the validator
(@polyspec/crudui-validator, packages/validator/ts) and the HTML renderer
(@polyspec/crudui-generator-html, packages/html), which writes the evaluated fields as
HTML. The React, Vue and Svelte adapters render the same model natively and are tested as
integrations of that implementation.