Developer vertical slice: SmartRegistry explicitly registers ten canonical,
source-backed Smart manifests for actions, fields, collections, status,
feedback and overlays. Real admin collections render the canonical
ui.dataview path with assets activated through core.assets. This does not
claim production readiness or readiness of every Larena package.
Documentation of SIMAI Framework and its components (in Russian): https://ui.simai.io/
The admin Smart components (sf-view-table, sf-view, sf-view-properties,
sf-admin-menu; the component package larena) used to live here in
components/. Since 2026-10-22 their source is
simai/ui-admin, in its components/
folder, under that repository's licence; their history up to the move stays
readable here (the last commit that wrote them is
1cee9e276c26834031153f25ac2a8f9ba5cbb26c). Versions published from this
repository remain Apache-2.0.
The component package is named pro (Framework owner decision q-4ac7d07595,
2026-11-02). Its built archive (package-pro.tar with its sha256 and receipt)
is published as release pro-<12> of simai/ui-pro, where Larena's installer
and checks fetch it: https://github.com/simai/ui-pro/releases. The archives
released here under the former name (larena-<12>, package-larena.tar) stay
as history: https://github.com/simai/larena-ui/releases.
Universal UI/frontend package for Larena smart components, backend-first rendering, hydration, design packs, UI asset graph, component registry, playground and frontend behavior contracts.
SmartRegistry is the canonical discovery point for generic UI manifests and
package contributions. The reference library contains ui.button, ui.input,
ui.textarea, ui.checkbox, ui.dropdown, ui.dataview, ui.pagination,
ui.badge, ui.alert and ui.modal. SmartManager renders every entry as its
pinned SIMAI Framework custom element; manifests declare the exact asset graph
for that element.
SmartCatalogProjection turns visible, complete manifests into localized typed
entries, and SmartAiCatalogProjection serializes the same entries as stable
machine-readable JSON. These projections never register components, invent
props or become a second source of truth.
use Larena\Ui\Facades\Smart;
$artifact = Smart::render(
'ui.button',
[
'text' => 'Save',
'size' => '1',
'type' => 'default',
'scheme' => 'primary',
'loading' => false,
'disabled' => false,
'native-type' => 'button',
'aria-label' => 'Save',
],
$assetActivation,
);The facade is the concise application call surface and resolves the
container-owned SmartManager; the manager remains the DI-first implementation
and testing boundary. The legacy Larena\Ui\Smart::render('sf-*') adapter stays
available for existing low-level frontend-tag callers.
JSON Smart View descriptors select a registered component view, safe defaults,
an optional preset and allowlisted modifiers without exposing PHP classes or
template paths. Applications render them through Smart::renderView(...).
Layout stores only stable component/view/preset/modifier identifiers; UI owns
their templates and validates the resolved props before using the same renderer
and asset path as Smart::render(...).
Composite views are rendered recursively with a bounded cycle/depth guard.
Each child remains a registered Smart View and contributes its verified assets;
runtime data may override props only for declared child identifiers, including
bounded nested overrides through _props and _children. The first
composition is admin.collection → dataview.table → dataview.toolbar + ui.dataview + ui.pagination; the toolbar itself composes replaceable
ui.input, ui.dropdown and ui.button views for search, filtering, sorting,
page size and submission.
Reference controls, presets and examples are derived from the same manifest.
SmartComponentReference normalizes allowlisted controls, while
SmartInvocationExampleBuilder produces inert PHP and frontend examples. It
does not evaluate generated code or accept arbitrary classes and templates.
Reference controls auto-submit the reproducible GET form; preview and code are
still generated by the backend rather than synthesized in JavaScript.
The package test suite changes and renders every one of the 48 exposed
controls. This guards the reference contract against controls that accept a
value without changing the real SmartManager output. Custom event names may use
stable colon-separated source names such as sf-dropdown:change; spaces,
slashes, malformed separators and on* handler-style names fail closed.
Every catalog entry reports render, data-binding and effect readiness
independently. Structured ui.dropdown.options and ui.dataview.data props
cannot be represented truthfully as custom-element attributes, so their
frontend examples are explicitly unavailable; backend examples and real
renders remain available. Values are never flattened or guessed. Provenance
exposes only package-relative resources/smart/.../manifest.json paths,
content hashes and pinned source revisions.
The current implementation is developer-testable and does not claim production readiness or readiness of all Larena packages.
The complete Admin Menu and Data View are reused as whole composite components.
Their editable, frontend-neutral contracts live with the canonical SF5 source in
ui-loader/src/smart/*/smart.manifest.json; Larena does not redefine that public
ABI. Run composer contracts:materialize from a workspace containing the
adjacent ui-loader checkout (or set SIMAI_UI_LOADER_REPO) to refresh the
verified snapshot in resources/contracts/.
resources/adapters/*.json is the Larena host projection. It declares backend
ownership, accepted server props, semantic-event transport and the exact source
contract version. SourceSmartContractCatalog fails closed when the snapshot
hash, schema, version, custom element, backend adapter mapping or event set
drifts. InstalledSmartAdapterCatalog exposes the verified public ABI together
with this host projection for both developers and AI consumers.
To change frontend behavior or the shared ABI, edit and test ui-loader first,
increment the contract version or add a compatibility migration, rebuild its
registry, then materialize the consumers. Larena-only access, persistence,
query and rendering rules belong in the Larena manifest/adapter and must remain
compatible with the source contract.
Canonical specifications are in simai/larena-specs.