ABAP on the left, the app it produces on the right, and nothing in between
but the browser. No server, no SAP system, no backend of any kind — the
page you are looking at is a static file, and everything below happens in
this tab. What the framework underneath it can do is in the
documentation
— which is also where the bar's Documentation goes, on a window wide
enough to carry the nav.
How it works
- The abap2UI5 sources are downported and translated to JavaScript at
build time, and bundled with the ABAP standard library into one module
this page loads.
- An in-memory SQLite, compiled to WebAssembly, takes the place of the
database abap2UI5 keeps its drafts in.
- abaplint parses the real framework sources so the editor can check
your class against them, and compiles only your classes when you press
Run — about twenty milliseconds. The
abap2UI5 linter
checks the view your builder chain produces against a UI5 release, which
is how an icon that does not exist gets reported at all.
- The abap2UI5 frontend runs in an iframe and talks to its backend over
a plain
fetch. The playground answers that one request from
the framework running in this page, so from the framework's point of
view nothing changed.
Where the apps come from
Samples above carries a handful of built-in samples to start
from and browses, without leaving this page, the samples of all three
sibling repositories - the same list the
sample catalog holds, which is where to go when
a search is worth linking to. What needs a real system is listed there
too, and stays where the system is:
- Learn
— the path through abap2UI5 itself, one idea per sample: bindings,
events, popups, navigation, whole apps.
- Controls
— the UI5 demo kit rebuilt in ABAP, searchable by control, by library
and by the release a sample needs.
- Stack
— abap2UI5 with OData, RAP, WebSockets or the launchpad. Those are the
one set that will not run here: they need a real system, which
is the whole point of them.
Credits
The playground is mostly wiring. Kudos goes to the projects it is wired
out of — and they are worth a look on their own:
- abaplint transpiler
— ABAP to JavaScript. The playground exists because this does.
- abaplint
— the parser, the syntax check and the language server behind the
editor's diagnostics, hover, rename and pretty printer.
- open-abap-core
— the ABAP standard library, written in ABAP and transpiled with
everything else. Every
CL_ABAP_* and CX_* you
use comes from here.
- OpenUI5
— the frontend, built into this site rather than linked from a CDN, so
the playground carries its own and works when nothing else does.
- Monaco
— the editor from VS Code.
- sql.js
— SQLite as WebAssembly, standing in for the database.
Read their code, star them, open the issue you ran into, send the pull
request. That is the thanks that reaches an open source project. Thank you.
Keyboard
- Ctrl Enter
- Run - the unit tests in a
.clas.testclasses.abap file first, then the app; also Ctrl S, which a browser would otherwise spend on saving the page. Auto beside it presses Run for you, shortly after you stop typing
- Ctrl Z / Y
- Undo and redo, per file
- Shift Alt F
- Format the open file
- F1
- Everything else the editor can do, by name
- F12 / F2
- Go to the definition under the cursor / rename it
- Esc
- Close a dialog, or the name being typed for a new file
Where it stops
A few classes, not a package: no tables of your own, no message classes,
no CDS. Nothing reaches outside the browser — no RFC, no files. Only what
the transpiler implements, and only the UI5 libraries built in. Your code
is kept in this browser; the app's data is not.
abap2UI5