abap2UI5/samples-controls

abap2UI5 — samples-controls

Learn how to use every UI5 control in ABAP — the UI5 Demo Kit rebuilt with abap2UI5.

You know the drill from the UI5 Demo Kit: pick a control, open its sample, copy the pattern. This repository brings that experience to ABAP — the official demo kit samples of ten UI5 libraries (sap.m, sap.f, sap.ui.core, sap.ui.layout, sap.ui.table, sap.ui.unified, sap.uxap, sap.tnt, sap.ui.codeeditor, sap.ui.integration), rebuilt 1:1 as ready-to-run abap2UI5 apps. Wondering how to express a control in ABAP? Its sample is already here — or on its way.

Try it in 60 seconds

1. Install abap2UI5.
2. Pull this repository with abapGit. What arrives: 642 classes in 15 packages — src/01 (401 ports, OpenUI5 ≤ 1.71, what every system renders), src/02 (221 ports that need a UI5 runtime newer than 1.71: they install and activate on any release, and on an older UI5 the newer control simply does not render), src/03 (the SAPUI5-only collection, which needs a SAPUI5 bootstrap) and src/04 (the demo kit's own demo apps — whole applications, one class each). ABAP-wise every class is Cloud-ready and runs from NetWeaver 7.02 on, see Compatibility. There are no per-library branches yet (unlike samples-stack, which ships one branch per package) — pulling the whole repository is the one way in, so expect the activation to take a few minutes.
3. Start z2ui5_cl_smpc_app_000 — every sample in one searchable table: each row links the original UI5 sample and its ABAP rebuild, and one click starts the app right in your system.

No ABAP system at hand? Open the sample catalogue — every port here, every sample of the other two repositories, filtered by control or by the UI5 release your system runs, each one a click from its source and from running in the browser playground.

Building with an AI coding agent? The AI page of the documentation sets up the skills and the MCP server — whose sample search covers every port here. In Claude Code it is two commands: /plugin marketplace add abap2UI5/abap2UI5, then /plugin install abap2ui5@abap2ui5.

The learning path

This repository is step 2 of 3 — the control reference of the abap2UI5 sample family:

	Repository	What you learn	Where to start
1️⃣	samples	the abap2UI5 basics — bindings, events, popups, navigation, complete apps	run Z2UI5_CL_SMP_APP_000
2️⃣	samples-controls — 📍 you are here	how to use every UI5 control — the UI5 Demo Kit rebuilt with abap2UI5	run z2ui5_cl_smpc_app_000
3️⃣	samples-stack	how abap2UI5 plays with your stack — OData, RAP, WebSockets, the Fiori Launchpad and more	pick your technology in its package table

Not only controls — the demo apps

src/04 answers the question the control samples cannot: can a whole UI5 application be built with abap2UI5? The demo kit's own demo apps — Manage Products, Browse Orders, the Shopping Cart — are rebuilt there, one class per app, router and all. Each class header names what its rebuild does differently from the original and why, so the cost of the answer is on the page next to the answer. The list is in SAMPLES.md; the originals are archived under ui5/demoapps/.

Learn by comparing

Every port keeps the structure of its original, so the two read side by side: the UI5 original (JS/XML) in ui5/, the ABAP rebuild in src/, and api.md as the full index — one row per demo kit sample, with links to both. The most effective way to learn a control: open its demo kit sample and its ABAP class next to each other and compare line by line.

How this repository is built — the generation pipeline

This repository is generated and gated by an AI coding agent: from every official demo kit sample of the covered libraries whose control is not deprecated (legacy-free ready), it builds an abap2UI5 app — exposing the functional gaps between what UI5 offers and what abap2UI5 can already express, so they can be closed. Deprecated controls are listed as out of scope; a control newer than UI5 1.71 is ported into src/02. The pipeline:

1. Read — clone OpenUI5 and scan every demo kit sample of the covered libraries (src/<library>/test/<library path>/demokit/sample/<Name>/, second segment with dots as slashes, e.g. src/sap.tnt/test/sap/tnt/…).
2. Generate — rebuild each sample 1:1 as an abap2UI5 app (z2ui5_if_app), filed under src/<category>/<library> (src/01/01 = OpenUI5 ≤ 1.71, sap.m — see AGENTS §3); both levels are derived from the port's meta/ sidecar.
3. Store templates — keep the original UI5 JS/XML templates in ui5/, one folder per sample — only ported samples are archived; each batch copies its samples over from the OpenUI5 checkout.
4. Report — regenerate the coverage tables and the in-system overview app. In api.md, — marks an in-scope sample not yet ported (the backlog), ⊘ one reserved as hold-out (in scope, unported on purpose) and ✗ an out-of-scope one (deprecated control, or not an app view).

Nothing graduates out of here. Since 2026-08-12 this repository is the home of the demo kit rebuilds (AGENTS.md §1) — checked is the top rung of the quality ladder, not a hand-off. Only three kinds of control sample live in the hand-maintained abap2UI5/samples repository instead: a 1.71-safe variant of a sample whose port here has to declare POST_171 (that repo is downported to 7.02), a sample in this repository's hold-out set (ui5/holdout.json), and a free-style control demo with no single demo kit original.

The generation prompt the porting agent is given — the condensed form of the porting recipe — is scripts/generation-prompt.txt. It is the single source: AGENTS.md §5 says when to change it, the port-a-sample guide is its authoritative long form, and abap2UI5's mcp-server serves that same file as its generation_rules rulebook.

Ports are filed by what a system needs to run them, then by library: src/01 (OpenUI5 ≤ 1.71 — the portable half), src/02 (needs a UI5 runtime newer than 1.71) and, under each, one package per library (01 = sap.m, 02 = sap.ui.*, 03 = sap.uxap, 04 = sap.f, 05 = sap.tnt). src/03 is flat and is not ports at all: it collects hand-written samples for SAPUI5-only controls, which have no OpenUI5 original to rebuild against. Both levels are derived from the port's meta/ sidecar, never chosen — see AGENTS §3 for the folder tables. The generation/review batch a port came from is recorded in its meta/<class>.json, not in the tree. This repository publishes no page of its own any more: the searchable catalogue over all three sample repositories lives in the playground and is built from catalogue-derived.json; see web/README.md for what went where.

Repo map

File	What it is
AGENTS.md	The complete generation rulebook (conventions, skeleton, gates) — CLAUDE.md points here
CONTRIBUTING.md	How to change a generated repository: what not to hand-edit, and the commands CI runs
CAPABILITIES.md	What abap2UI5 can express — each entry backed by a proving port or a source-verified trace
TRAINING.md	The improvement loop: batches, quality ladder, reference repositories
STATUS.md	Generated point-in-time state + the open findings backlog
E2E.md	How to run and debug the Playwright e2e smoke against the real transpiled backend
SAMPLES.md	The catalogue: every port with what it shows, grouped by UI5 library — the same page shape as samples and samples-stack
api.md	One row per demo kit sample: ported, backlog, reserved as hold-out, or out of scope
meta/	One sidecar per port — status, checked, typed deviations
ui5/	The archived original demo kit template of every ported sample, plus the scope/universe snapshots the coverage is computed from
scripts/	The generators and the gates — one script per CI job, plus generation-prompt.txt, the porting agent's prompt
catalogue.json, catalogue-derived.json	The machine-readable index: the tree's facts, and what the linter knows about each port (controls built, minimum UI5 release) — joined on class, and what the catalogue page is built from
docs/history.md	The chronological journal — batches, probes, audits, one section per event
docs/upstream-requests.md	The record of what porting asked the framework for — implemented and declined. Open requests live in backlog/ in abap2UI5, where the whole ecosystem's upstream backlog is
mcp-server	MCP server for AI coding agents — capability queries, view validation, deploy, headless run + screenshot on this repo's infrastructure (separate repository)
abap2UI5-linter	The view gates as standalone CLI, library and GitHub Action — extracted from this repo and now used BY it (scripts/view-gates.mjs)

Compatibility

Every app is ABAP Cloud ready and downportable to 7.02. In detail, every app:

• uses only controls available since UI5 1.71 (16 Jan 2020), none of them deprecated (legacy-free ready). Individual members newer than 1.71 are kept where the original sample uses them — declared per port (POST_171), so those apps need a correspondingly recent UI5;
• runs on SAPUI5 and OpenUI5, including the legacy-free runtime;
• runs on ABAP Cloud and ABAP Standard, and downports to 7.02.

CI enforces this on every change:

Each check is a workflow of its own, so a red badge names the thing that is actually broken:

Workflow	What it does
abap-standard	abaplint ./abaplint.jsonc (syntax v750)
abap-cloud	abaplint .github/abaplint/abap_cloud.jsonc (syntax Cloud)
abap-702	npm run downport → abaplint .github/abaplint/abap_702.jsonc
view-gates	abap2UI5-linter per port: UI5 metadata, builder structure, headless XMLView.create — plus check:collection for the SAPUI5-only classes
structural-diff	port vs. original view incl. binding values; an undeclared deviation fails
data-fidelity	seeded values vs. the archived sample mocks
pattern-lint	the corpus-policy rules distilled from review findings
chain-format	the view-chain layout (npm run fmt:chains fixes it)
meta-valid	sidecar schema + referential integrity, and every generated artefact in sync
check-pins	the abap2UI5 pin policy (A2UI5_PIN, no stray dependency branch)
check-app-rules, check-keywords, check-summary, check-prose-names	the shared abaplint app rules, the @keywords/@summary lines, and every class name written in prose
tooling-tests	the gate/generator tooling's own fixture tests
e2e-nightly	every port booted as the real app in headless Chromium (scheduled)

Every port also carries a machine-readable sidecar meta/<class>.json (sample, status, declared deviations) — the source of truth the overview app, the coverage and the structural diff read from.

Coverage

Coverage per UI5 library — the share of official demo kit samples that already have an abap2UI5 port.

Overall 669 / 669 portable demo kit samples ported (100.0 %). In scope: samples whose control is not deprecated (legacy-free ready). 52 of them use a control newer than UI5 1.71 — their ports need a newer runtime and are filed under src/02. Out of scope: 61 of 742 samples — 21 on deprecated controls, 37 that are not app views (UI5 test infrastructure, Component routing, view-templating demos — see ui5/scope-nonapp.json), 3 demo apps without an owning control. Plus 1 ported samples outside that scope — maintainer-decided exceptions (ui5/scope-exceptions.json, listed in STATUS.md); they are not counted as coverage of the in-scope backlog. Control metadata from OpenUI5 1.152.0.

Module	Samples	In scope	Reserved	To port	Ported	Coverage
sap.f	46	46		46	46	100.0 %	██████████
sap.m	461	442	12	430	430	100.0 %	██████████
sap.tnt	17	17		17	17	100.0 %	██████████
sap.ui.codeeditor	2	2		2	2	100.0 %	██████████
sap.ui.core	63	21		21	21	100.0 %	██████████
sap.ui.integration	4	4		4	4	100.0 %	██████████
sap.ui.layout	61	61		61	61	100.0 %	██████████
sap.ui.table	21	21		21	21	100.0 %	██████████
sap.ui.unified	22	22		22	22	100.0 %	██████████
sap.uxap	45	45		45	45	100.0 %	██████████
Total	742	681	12	669	669	100.0 %	██████████

Reserved — 12 in-scope samples are deliberately not ported. They are the hold-out set (ui5/holdout.json, see TRAINING.md): never used as prompt references, kept out of batch planning, and regenerated from scratch to measure the generator itself — CI-green on the first try, structural-diff violations, review findings per app. Spending one as a measurement is what ports it, so they leave this column by being used, not by being worked off. They are excluded from the coverage denominator because they are not backlog. The portable backlog is zero.

For the full control-level view — one row per sample (Module · Control · Since · Deprecated · Sample · ABAP), every link pointing at OpenUI5 — see api.md, or the in-system overview app z2ui5_cl_smpc_app_000, where the Sample column links the OpenUI5 source (its ↗ opens the live sample) and the abap2UI5 column links the generated class (its ↗ starts the app in the system).

The coverage summary and api.md are generated by the generate-result workflow (scripts/generate-coverage.mjs), and the overview app by scripts/generate-overview.mjs, both from the latest OpenUI5 demo kit samples — do not edit them by hand.

Dependencies

• abap2UI5

License

The code of this repository is MIT. The originals it rebuilds are not: everything under ui5/ is copied from OpenUI5 — © SAP SE or an SAP affiliate company and OpenUI5 contributors, Apache License 2.0 — and the ports under src/ are derivative works of those samples, translated to ABAP (each port's deviations from its original are listed in its meta/ sidecar). See ui5/README.md for the details. This is a community project and not affiliated with or endorsed by SAP; SAP, UI5, SAPUI5 and the SAP logo are trademarks of SAP SE.

Issues

For bug reports or feature requests, please open an issue in the abap2UI5 repository.

---

Last generated: 2026-08-17 03:53 UTC