abap2UI5 · oblomov-dev · Aug 16, 2026 · Aug 16, 2026
diff --git a/docs/advanced/addons.md b/docs/advanced/addons.md
@@ -5,15 +5,15 @@ outline: [2, 4]
 
 abap2UI5 focuses on core capabilities — rendering views, handling events, and exchanging data. This keeps the framework lean and easy to maintain. The real strength lies in the ecosystem: **ready-to-use add-ons and community projects** that extend abap2UI5 for specific needs.
 
-#### Available Add-ons
+## Available Add-ons
 
 Browse the [abap2UI5-addons](https://github.com/abap2UI5-addons) organization to find what you need. Features include:
 - Layout variant handling, similar to classic SAP GUI selection screens or ALV reports
 - Table maintenance tools
 - Integration with third-party libraries like Chart.js for richer charts
 - And many more
 
-#### Open Source Projects
+## Open Source Projects
 
 Other open-source projects use abap2UI5 — try them out:
 
@@ -26,6 +26,6 @@ Other open-source projects use abap2UI5 — try them out:
 | [table-content-loader](https://github.com/abap2UI5-apps/table-content-loader) | Upload & download table content  |
 | [table-maintenance](https://github.com/abap2UI5-addons/table-maintenance) | Table maintenance in your browser |
 
-#### Contribution
+## Contribution
 
 Built a feature or your own open-source project with abap2UI5? Contribute to existing repositories or start your own. Add your project here so others can find, use, and contribute to your work.
diff --git a/docs/advanced/downporting.md b/docs/advanced/downporting.md
@@ -5,7 +5,7 @@ outline: [2, 4]
 
 abap2UI5 works right away on ABAP 7.50 and later. On an earlier release, install the downported version, which supports R/3 NetWeaver 7.02 and later.
 
-#### Branch
+## Branch
 To install on an older system, use the `702` branch:
 | Branch    | System                |
 |-----------| ----------------------------|
@@ -14,7 +14,7 @@ To install on an older system, use the `702` branch:
 
 Some sample projects and other repositories also ship a downported version. Check whether a `702` branch is available.
 
-#### Installation
+## Installation
 The installation on an old release follows the normal [installation](/configuration/installation) flow with two adjustments:
 1. Pull the `702` branch with abapGit — abapGit itself is 7.02-compatible, so deployment to old ECC machines works the same way as everywhere else
 2. Create the HTTP handler (SICF service) with the 7.02-compatible handler syntax instead of the modern snippet
@@ -23,7 +23,7 @@ After that, call your HTTP handler from the browser and abap2UI5 is ready for us
 
 If you later want to reach these apps from the cloud, use the [RFC Connector](/advanced/rfc): it calls abap2UI5 apps on legacy systems via BTP destination and RFC, integrating them into Steampunk, S/4 Public Cloud, Fiori Launchpads, or SAP Mobile Start. The [HTTP Connector](/advanced/http) offers the same over HTTP.
 
-#### How It Works
+## How It Works
 The `702` branch is not maintained by hand — it is **generated** from `main` by an automated GitHub Actions workflow on every change. The pipeline runs [abaplint](https://abaplint.org)'s downport rule (`abaplint --fix` with a 7.02 target configuration), which rewrites modern syntax into 7.02-compatible equivalents, for example:
 
 - inline declarations `DATA(x) = ...` → separate `DATA` statements
@@ -35,7 +35,7 @@ A few small compatibility fix-ups follow (e.g. replacing exception types that do
 
 The same mechanism runs in this project's CI (`npm run auto_downport`) to guarantee every change on `main` stays downportable.
 
-#### Why abap2UI5 Is Downportable
+## Why abap2UI5 Is Downportable
 Automatic syntax rewriting is only the last step. The codebase is compatible with everything from ABAP 7.02 up to the newest ABAP Cloud because of four design principles:
 
 **1. Only basic technology.** No OData services, CDS views, or new EML syntax — none of these exist on older ECCs. Conversely, no SAP GUI or other statements forbidden in ABAP Cloud. The only universally available technology is a plain HTTP service (defined via SICF on-premise, via Eclipse in the cloud), and that is all abap2UI5 needs for communication.
@@ -48,5 +48,5 @@ Automatic syntax rewriting is only the last step. The codebase is compatible wit
 
 Keep these principles in mind if you want to set up your next abapGit project with compatibility for older releases.
 
-#### Further Reading
+## Further Reading
 Background article: [Running abap2UI5 on older R/3 Releases](https://www.linkedin.com/pulse/running-abap2ui5-older-r3-releases-downport-compatibility-abaplint-mjkle).
diff --git a/docs/advanced/extensibility/custom_control.md b/docs/advanced/extensibility/custom_control.md
@@ -7,11 +7,11 @@ You can build your own UI5 custom controls and use them in abap2UI5 apps.
 
 First, set up your VS Code environment with the abap2UI5 frontend artifacts, following the [Frontend](/advanced/extensibility/frontend) page.
 
-#### Frontend
+## Frontend
 
 Write the JavaScript for your new custom control. Each custom control lives in its own file under [app/webapp/cc/](https://github.com/abap2UI5/abap2UI5/tree/main/app/webapp/cc) — copy an existing one (e.g. `Timer.js`) and adapt it to your needs.
 
-#### Backend
+## Backend
 
 Nothing. The current view builder has no method per control, so a custom
 control needs no backend counterpart — write the element and its properties

diff --git a/docs/advanced/extensibility/frontend.md b/docs/advanced/extensibility/frontend.md
@@ -5,7 +5,7 @@ outline: [2, 4]
 
 The abap2UI5 frontend artifacts live in the `app` folder. To adjust them:
 
-#### Setup
+## Setup
 Open VS Code (or your editor of choice), then run in the terminal:
 ```sh
 git clone https://github.com/abap2UI5/abap2UI5
@@ -15,7 +15,7 @@ Next replace `<<system>>` in the three config files — `ui5.yaml`, `ui5-local.y
 
 <img width="400" alt="Frontend config files where the backend system URL must be replaced" src="https://github.com/user-attachments/assets/155c9a3f-8a0a-494b-8fc4-a4bba2bf0e90">
 
-#### Build & Test
+## Build & Test
 If your HTTP service uses a different path, also replace `/sap/bc/z2ui5` with your endpoint in the manifest. Then run:
 ```sh
 npm i
@@ -24,7 +24,7 @@ npm run start-noflp
 You'll see output like this:
 <img width="1000" alt="npm run start-noflp output showing the local dev server running" src="https://github.com/user-attachments/assets/3e0118e8-d05f-48d1-bcc0-28073adf6e47">
 
-#### Before PR (Optional)
+## Before PR (Optional)
 Convert the UI5 app to stringified ABAP:
 ```sh
 cd ..

diff --git a/docs/advanced/fiori.md b/docs/advanced/fiori.md
@@ -7,7 +7,7 @@ Extend the object page of a Fiori list report app with an abap2UI5 app. See the
 
 <img width="747" height="387" alt="abap2UI5 app embedded in Fiori Elements object page" src="https://github.com/user-attachments/assets/c14d5732-3b8c-4fa5-83ab-6d188a4d87db" />
 
-### Guide
+## Guide
 
 1. Register the FLP integration in the component.js:
 

diff --git a/docs/advanced/http.md b/docs/advanced/http.md
@@ -5,18 +5,18 @@ outline: [2, 4]
 
 The [abap2UI5 HTTP Connector](https://github.com/abap2UI5-addons/http-connector) calls abap2UI5 apps remotely over HTTP between two ABAP systems. It works similarly to the [RFC Connector](./rfc.md), but uses HTTP instead of RFC as the communication channel.
 
-#### When to use
+## When to use
 The HTTP Connector enables several useful cases:
 - Frontend/Backend Split: abap2UI5 apps live in the backend, but users access them through a separate frontend system
 - Legacy Systems (e.g., ECC): downport abap2UI5 to older systems and call it over HTTP from a newer system
 - Multi-System Landscapes: one entry point reaches abap2UI5 apps spread across multiple systems
 - Cross-Network Scenarios: HTTP is often easier to route through firewalls, reverse proxies, and gateways than RFC
 
-#### Architecture
+## Architecture
 
 The system that calls the app (the frontend system) ships with the UI5 library and bootstraps the UI. The system that runs the app (the backend system) doesn't need to host the UI5 runtime — it only exposes its abap2UI5 endpoint over HTTP.
 
-#### Installation
+## Installation
 
 _Prerequisite: Set up an SM59 HTTP destination pointing to the backend system (the system that runs the apps). Install abap2UI5 on both systems._
 
@@ -25,5 +25,5 @@ Steps:
 2. In the HTTP handler, configure the destination to point to the backend system
 3. In your browser, call the HTTP Connector's endpoint on the frontend system (the ICF service installed with the connector — analogous to `.../sap/bc/2ui5_rfc` for the RFC Connector)
 
-#### Further Information
+## Further Information
 For the latest details, source code, and updates, see the [HTTP Connector repository on GitHub](https://github.com/abap2UI5-addons/http-connector).
diff --git a/docs/advanced/legacy_free.md b/docs/advanced/legacy_free.md
@@ -5,11 +5,11 @@ outline: [2, 4]
 
 The abap2UI5 frontend is also available as a **legacy-free** variant, bootstrapped from the new legacy-free distribution of OpenUI5 (`1.142.0-legacy-free`) — the build without `jQuery.sap.*`, synchronous APIs, and other deprecated globals. It is essentially a preview of the API surface that UI5 2.x will enforce.
 
-### What is UI5 Legacy-Free?
+## What is UI5 Legacy-Free?
 
 `*-legacy-free` is a parallel distribution of OpenUI5/SAPUI5 (starting with the 1.136.x line) that ships the same controls and APIs as the regular 1.x build, but with everything deprecated removed up front. In practice that means no `jQuery.sap.*`, no `sap.ui.getCore()`, no synchronous module loading (`sap.ui.requireSync`, sync XHR), no global view/controller factories, no jQuery bundled into the core, and none of the compatibility shims that 1.x kept around for backwards compatibility.
 
-### Why It Matters for the Future
+## Why It Matters for the Future
 
 UI5 2.x — the next major release line — will enforce exactly this surface. By developing against the legacy-free build today, the project gets several things at once:
 
@@ -21,7 +21,7 @@ UI5 2.x — the next major release line — will enforce exactly this surface. B
 
 In short: the legacy-free build is the bridge between today's UI5 1.x ecosystem and tomorrow's UI5 2.x. Building the abap2UI5 frontend on it now means the framework is ready for 2.x the day it lands, instead of chasing it afterwards.
 
-### Installation
+## Installation
 
 The legacy-free frontend ships as the `v2` branches of the [frontend repository](https://github.com/abap2UI5/frontend). Pull the branch that matches your system into your ABAP system with [abapGit](https://abapgit.org) and activate — there is no separate build step:
 
@@ -36,13 +36,13 @@ The v2 branches install the frontend under the same `z2ui5` name as the classic
 The former separate repository `abap2UI5/frontend-legacy-free` is obsolete. The legacy-free frontend is now maintained on the `*_v2` branches of the [frontend repository](https://github.com/abap2UI5/frontend), generated from the same single source as the classic variant.
 :::
 
-### Why Try the v2 Version?
+## Why Try the v2 Version?
 
 - **Future-proof.** Apps already run on what UI5 2.x will require — no big-bang migration later.
 - **Smaller and faster.** No jQuery and no compatibility layers means a leaner core and quicker startup.
 - **Cleaner foundation.** Modern async patterns, no hidden globals, better alignment with current web standards.
 
-### Learn More
+## Learn More
 
 - [Available OpenUI5 versions](https://sdk.openui5.org/versionoverview.html) (incl. `*-legacy-free` builds)
 - [Explore SAPUI5/OpenUI5 1.136.x-legacy-free (SAP Community)](https://community.sap.com/t5/technology-blog-posts-by-sap/explore-sapui5-openui5-1-136-x-legacy-free/ba-p/14103271)

diff --git a/docs/advanced/renaming.md b/docs/advanced/renaming.md
@@ -10,7 +10,7 @@ prefix, which is what makes several installations in one system possible.
 
 ## The `z2ui5` Namespace
 
-#### Why a Prefix and Not a Package
+### Why a Prefix and Not a Package
 ABAP has no package manager. Every object abapGit pulls is created **globally**
 in the system, so two installations cannot hide behind their package the way two
 npm modules hide behind `node_modules`. The only thing that keeps objects apart
@@ -29,7 +29,7 @@ will overwrite yours.
 | Exception class | `z2ui5_cx_*` | `z2ui5_cx_ui5_util_error` |
 | DDIC table | `z2ui5_t_*` | `z2ui5_t_01` |
 
-#### The Second Segment
+### The Second Segment
 The scheme the abap2UI5 repositories share is
 `z2ui5_<type>_<segment>_<object>` — a name has one more part than the prefix
 suggests:
@@ -97,7 +97,7 @@ segment. abaplint's own naming rule only checks the `Z2UI5_` prefix, so without
 that gate a new segment would drift in unnoticed.
 :::
 
-#### Package Layout
+### Package Layout
 The prefix is flat, the packages are not. abapGit is configured with
 `FOLDER_LOGIC=PREFIX`, so the folders of a repository become the package
 hierarchy in your system. For the framework repository that is:
@@ -112,7 +112,7 @@ hierarchy in your system. For the framework repository that is:
 The package a class sits in is the honest answer to "may I use this?": `src/02`
 yes, `src/01` no, `src/99` only if your app already does.
 
-#### Name Length
+### Name Length
 ABAP object names are limited to 30 characters, and abap2UI5 does not spend all
 of them: every object name in `src/` stays at **25 characters or less**. The
 remaining five are headroom for renaming — a namespace of up to 10 characters
@@ -122,7 +122,7 @@ This is why the generated frontend classes carry compressed names like
 `z2ui5_cl_ui5f_scrfocus_js` rather than spelled-out ones: the generator caps them
 and fails rather than truncating silently.
 
-#### The Frontend Namespace
+### The Frontend Namespace
 `z2ui5` exists a second time — in the browser, as the UI5 module namespace. It is
 a **different namespace that happens to share the name**, and it is not an ABAP
 object at all:
@@ -140,7 +140,7 @@ installation, renamed or not. That is deliberate: the frontend namespace lives
 inside one browser page, where only one abap2UI5 installation is ever loaded, so
 there is nothing for it to collide with.
 
-#### Your Own Objects
+### Your Own Objects
 Nothing about the framework's naming applies to your apps. An app is a class in
 your own namespace that implements `z2ui5_if_app`:
 
@@ -166,7 +166,7 @@ requirements, like:
 abap2UI5 works with the abaplint renaming feature and supports namespaces up to
 10 characters, e.g., `zabap2ui5`.
 
-#### Why Rename?
+### Why Rename?
 Because objects are global, a system can hold only **one** version of abap2UI5 —
 and every app in the system is forced to use it. Pulling the latest version can
 then break existing apps. Public API changes are kept to a minimum, but a
@@ -178,7 +178,7 @@ and upgrade each installation at its own pace. At the app level, you simply
 implement the renamed app interface — e.g., `z2ui5_sd_if_app` or `z2411_if_app`
 instead of `z2ui5_if_app`.
 
-#### How It Works
+### How It Works
 [abaplint](https://abaplint.org) can rename ABAP artifacts across a whole repository: you define rename patterns (old name → new name, including regular expressions) in an abaplint configuration, and `abaplint --rename` rewrites every class, interface, and reference consistently, writing the result to an output folder:
 
 ```jsonc
@@ -192,7 +192,7 @@ instead of `z2ui5_if_app`.
 
 The renamed copy is a complete, installable abapGit project under your own namespace — install it side by side with the original, pin it to a release, or ship it inside your product. The abap2UI5 CI runs this transformation on every change (`npm run rename`, workflow `test_rename.yaml`) to guarantee the codebase stays renameable.
 
-#### Step-by-Step Guide
+### Step-by-Step Guide
 Everything is already set up in the main repository: the on-demand GitHub Action `build_rename` renames all artifacts to a namespace of your choice and pushes the result as a ready-to-install branch. Renaming abap2UI5 takes just two steps:
 
 1. **Fork** the [abap2UI5 repository](https://github.com/abap2UI5/abap2UI5)
@@ -202,7 +202,7 @@ The workflow runs `abaplint --rename` with the checked-in configuration `.github
 
 To upgrade an installation later, sync your fork with upstream and re-run the workflow with the same name: the branch is updated to the current state (nothing is pushed when there are no content changes), and you simply pull again with abapGit.
 
-#### What Renaming Does Not Cover
+### What Renaming Does Not Cover
 abaplint rewrites object names and every reference the compiler can see. Three
 things fall outside that, and it is worth knowing them before you ship a renamed
 installation.
@@ -236,9 +236,9 @@ such as `/ZZZ/` is a regular expression away in the abaplint configuration, but
 it is not what the workflow builds, and the namespace has to exist in the target
 system before you can import objects into it.
 
-#### Renaming in Practice: ajson
+### Renaming in Practice: ajson
 abap2UI5 itself relies on this feature: its JSON handling comes from the open-source project [ajson](https://github.com/sbcgua/ajson), which is integrated under the `z2ui5` namespace via renaming — so there are no collisions if you pull both abap2UI5 and ajson separately into the same system. A GitHub Action in the [mirror-ajson](https://github.com/abap2UI5/mirror-ajson) repository checks weekly for upstream changes and automatically creates a pull request with the latest ajson version renamed to `z2ui5`. abapGit bundles ajson under its own namespace the same way — renaming with abaplint also makes it possible to integrate open-source projects into each other.
 
-#### Further Reading
+### Further Reading
 - [Automagic standalone renaming of ABAP objects](https://community.sap.com/t5/application-development-blog-posts/automagic-standalone-renaming-of-abap-objects/ba-p/13499851)
 - [Renaming of ABAP Artifacts — The Power of abaplint and abapGit in ABAP Development](https://www.linkedin.com/pulse/renaming-abap-artifacts-power-abaplint-github-actions-development-kqede/)
diff --git a/docs/advanced/rfc.md b/docs/advanced/rfc.md
@@ -5,19 +5,19 @@ outline: [2, 4]
 
 The [abap2UI5 RFC Connector](https://github.com/abap2UI5-addons/rfc-connector) calls abap2UI5 apps remotely over RFC between two ABAP systems. This is handy in distributed system landscapes or with legacy systems that can't directly host UI5 frontend logic.
 
-#### When to use
+## When to use
 The RFC Connector enables several useful cases:
 - Frontend/Backend Split: abap2UI5 apps live in the backend, but users can only access the frontend server
 - Legacy Systems (e.g., ECC): downport abap2UI5 to older systems and call it from a newer system over RFC
 - Multi-System Landscapes: one entry point reaches abap2UI5 apps spread across multiple systems
 
-#### Architecture
+## Architecture
 
 The system that calls the app (the frontend system) ships with the UI5 library and bootstraps the UI. The system that runs the app (the backend system) doesn't need to host the UI5 runtime.
 
 <img width="600" alt="abap2UI5 RFC Connector architecture across frontend and backend systems" src="https://github.com/user-attachments/assets/6f885f04-2b70-4cb3-83d0-123473b72262" />
 
-#### Installation
+## Installation
 
 _Prerequisite: Set up an SM59 destination to call the backend system (the system that runs the apps) over RFC. Install abap2UI5 on both systems._
 
@@ -26,12 +26,12 @@ Steps:
 2. In the HTTP handler, replace the destination `NONE` with the RFC destination pointing to the backend system
 3. In your browser, call the endpoint `.../sap/bc/2ui5_rfc`
 
-#### UI5 Bootstrapping
+## UI5 Bootstrapping
 The backend system that holds the abap2UI5 apps needs no UI5 libraries. The calling system bootstraps them automatically:
 
 <img width="600" alt="UI5 bootstrap loaded from calling system while backend hosts the app logic" src="https://github.com/user-attachments/assets/8e7dd3dd-abd3-413f-8ec6-8a7a2be7a7ec" />
 
-#### Multi-System Launchpad
+## Multi-System Launchpad
 You can also use this approach to build a unified Fiori Launchpad that combines:
 - Apps installed on-stack (on the current system)
 - Apps called remotely over RFC from other systems