abap2UI5 · oblomov-dev · Sep 2, 2026 · Sep 2, 2026
diff --git a/docs/advanced/insights/01-somewhere-on-the-way-to-ui5.md b/docs/advanced/insights/01-somewhere-on-the-way-to-ui5.md
@@ -1,4 +1,4 @@
-# Somewhere on the Way to UI5, We Lost RTTS
+# #1 Somewhere on the Way to UI5, We Lost RTTS
 
 
 ![The dinosaur at a classic ALV grid, the sheep and the sloth at the same table

diff --git a/docs/advanced/insights/02-not-a-programming-model.md b/docs/advanced/insights/02-not-a-programming-model.md
@@ -1,4 +1,4 @@
-# abap2UI5 is not a Programming Model
+# #2 abap2UI5 is not a Programming Model
 
 The useful question about a UI framework is not what it can do. It is what it
 wants from you: a structure to follow, a lifecycle to fit into, layers to fill

diff --git a/docs/advanced/insights/03-the-cost-of-a-screen.md b/docs/advanced/insights/03-the-cost-of-a-screen.md
@@ -1,4 +1,4 @@
-# The Cost of a Screen
+# #3 The Cost of a Screen
 
 An ABAP team needs a screen. Not an application — a screen. A maintenance view
 for a customising table nobody wants to explain in SM30. A cockpit showing what

diff --git a/docs/advanced/insights/04-no-annotation-in-between.md b/docs/advanced/insights/04-no-annotation-in-between.md
@@ -1,4 +1,4 @@
-# No Annotation in Between
+# #4 No Annotation in Between
 
 In a metadata-driven UI a screen is described rather than written. The
 description has a vocabulary — line items, selection fields, facets,

diff --git a/docs/advanced/insights/05-ui5-over-the-wire.md b/docs/advanced/insights/05-ui5-over-the-wire.md
@@ -1,4 +1,4 @@
-# UI5 Over-the-Wire
+# #5 UI5 Over-the-Wire
 
 A UI5 freestyle app is a single-page application. The view is deployed with the
 app in the frontend, the backend delivers data through OData, and the browser

diff --git a/docs/advanced/insights/06-the-frontend-that-does-not-know.md b/docs/advanced/insights/06-the-frontend-that-does-not-know.md
@@ -1,4 +1,4 @@
-# The Frontend Knows Nothing
+# #6 The Frontend Knows Nothing
 
 The first GET request delivers a UI5 app to the browser. It is worth asking
 what is actually in it.

diff --git a/docs/advanced/insights/07-one-service-for-every-app.md b/docs/advanced/insights/07-one-service-for-every-app.md
@@ -1,4 +1,4 @@
-# The Same Service for Every App
+# #7 The Same Service for Every App
 
 Count what a screen usually costs in backend artefacts. A CDS view or two, a
 service definition, a service binding, a behavior definition and its

diff --git a/docs/advanced/insights/08-only-the-changed-part.md b/docs/advanced/insights/08-only-the-changed-part.md
@@ -1,4 +1,4 @@
-# Only the Changed Part
+# #8 Only the Changed Part
 
 If the backend sends the view on every request, does the screen rebuild itself
 on every click?

diff --git a/docs/advanced/insights/09-public-means-persisted.md b/docs/advanced/insights/09-public-means-persisted.md
@@ -1,4 +1,4 @@
-# PUBLIC Means Persisted
+# #9 PUBLIC Means Persisted
 
 Every request lands on a fresh instance of the app class. No session holds the
 previous one, and the next request may not even reach the same application

diff --git a/docs/advanced/insights/10-swapping-the-view-at-runtime.md b/docs/advanced/insights/10-swapping-the-view-at-runtime.md
@@ -1,4 +1,4 @@
-# Swapping the View at Runtime
+# #10 Swapping the View at Runtime
 
 The view is a string the app produced for this request. Which raises an
 uncomfortable question: what stops the next request from producing a different

diff --git a/docs/advanced/insights/11-index-html-lives-in-a-string.md b/docs/advanced/insights/11-index-html-lives-in-a-string.md
@@ -1,4 +1,4 @@
-# index.html Lives in a String
+# #11 index.html Lives in a String
 
 Somebody has to deliver the first HTML page. In the SAP world that normally
 means a BSP application: a frontend artefact, built somewhere, deployed to the

diff --git a/docs/advanced/insights/12-where-your-own-javascript-goes.md b/docs/advanced/insights/12-where-your-own-javascript-goes.md
@@ -1,4 +1,4 @@
-# Where Your Own JavaScript Goes
+# #12 Where Your Own JavaScript Goes
 
 Sooner or later an app needs something the XML view cannot express. A chart
 library. A control nobody has wrapped. A UI5 method that exists only as a

diff --git a/docs/advanced/insights/13-four-verbs.md b/docs/advanced/insights/13-four-verbs.md
@@ -1,4 +1,4 @@
-# Four Verbs
+# #13 Four Verbs
 
 The first view builder in abap2UI5 had one method per UI5 control. `button( )`,
 `input( )`, `table( )` — hundreds of them, each with the control's properties as

diff --git a/docs/advanced/insights/14-the-class-that-runs.md b/docs/advanced/insights/14-the-class-that-runs.md
@@ -1,4 +1,4 @@
-# The Class That Runs
+# #14 The Class That Runs
 
 Every ABAP developer already knows the smallest program that does something:
 

diff --git a/docs/advanced/insights/15-where-the-selection-screen-went.md b/docs/advanced/insights/15-where-the-selection-screen-went.md
@@ -1,4 +1,4 @@
-# Where the Selection Screen Went
+# #15 Where the Selection Screen Went
 
 Before anyone called it full-stack, ABAP had this:
 

diff --git a/docs/advanced/insights/16-no-cache-no-deploy-any-ide.md b/docs/advanced/insights/16-no-cache-no-deploy-any-ide.md
@@ -1,4 +1,4 @@
-# No Cache, No Deploy, Any IDE
+# #16 No Cache, No Deploy, Any IDE
 
 The loop is: change the class, activate, refresh the browser.
 

diff --git a/docs/advanced/insights/17-one-codebase-702-to-abap-cloud.md b/docs/advanced/insights/17-one-codebase-702-to-abap-cloud.md
@@ -1,4 +1,4 @@
-# One Codebase, 7.02 to ABAP Cloud
+# #17 One Codebase, 7.02 to ABAP Cloud
 
 Most SAP landscapes are currently two landscapes. Something old that runs the
 business, something new that is being built beside it, and a migration between

diff --git a/docs/advanced/insights/18-cloud-ready-is-a-property-of-your-app.md b/docs/advanced/insights/18-cloud-ready-is-a-property-of-your-app.md
@@ -1,4 +1,4 @@
-# Cloud-Ready Is a Property of Your App
+# #18 Cloud-Ready Is a Property of Your App
 
 The framework is ABAP Cloud compliant. It is written in the ABAP for Cloud
 language version, it calls released APIs only, it modifies no standard SAP

diff --git a/docs/advanced/insights/19-when-the-api-is-not-released.md b/docs/advanced/insights/19-when-the-api-is-not-released.md
@@ -1,4 +1,4 @@
-# When the API Is Not Released
+# #19 When the API Is Not Released
 
 SAP grades an extension, and since August 2025 it does so on four **clean core
 levels**:

diff --git a/docs/advanced/insights/20-on-stack-or-side-by-side.md b/docs/advanced/insights/20-on-stack-or-side-by-side.md
@@ -1,4 +1,4 @@
-# On-Stack or Side-by-Side
+# #20 On-Stack or Side-by-Side
 
 Two places to run an abap2UI5 app, and the choice is about lifecycles rather
 than about code.

diff --git a/docs/advanced/insights/21-one-app-many-systems.md b/docs/advanced/insights/21-one-app-many-systems.md
@@ -1,4 +1,4 @@
-# One App, Many Systems
+# #21 One App, Many Systems
 
 A side-by-side app already runs outside the system it serves. Which raises a
 question with a more interesting answer than it looks: how many systems can it

diff --git a/docs/advanced/insights/22-2300-lines.md b/docs/advanced/insights/22-2300-lines.md
@@ -1,4 +1,4 @@
-# 2,300 Lines
+# #22 2,300 Lines
 
 The communication core of abap2UI5 is one HTTP handler class, two interfaces
 and one database table. Originally about 2,300 lines of ABAP. The framework has

diff --git a/docs/advanced/insights/23-abap-on-the-web.md b/docs/advanced/insights/23-abap-on-the-web.md
@@ -1,4 +1,4 @@
-# From ITS to abap2UI5
+# #23 From ITS to abap2UI5
 
 Worth laying out end to end, because the shape of it is not what most people
 remember.

diff --git a/docs/advanced/insights/24-where-the-line-is.md b/docs/advanced/insights/24-where-the-line-is.md
@@ -1,4 +1,4 @@
-# What It Does Not Do
+# #24 What It Does Not Do
 
 Before choosing anything, the part that is easiest to leave out: what this
 does not do.

diff --git a/docs/advanced/insights/25-where-the-view-lives.md b/docs/advanced/insights/25-where-the-view-lives.md
@@ -1,4 +1,4 @@
-# Where the View Lives
+# #25 Where the View Lives
 
 Three ways to put a UI5 screen in front of a user on an ABAP stack. All three
 render in the browser, with the same control library, through the same

diff --git a/docs/advanced/insights/26-rap-or-abap2ui5.md b/docs/advanced/insights/26-rap-or-abap2ui5.md
@@ -1,4 +1,4 @@
-# RAP or abap2UI5 — When to Use Which
+# #26 RAP or abap2UI5 — When to Use Which
 
 The honest answer is that most systems end up with both, and the question is
 never "which framework" but "which one for this screen".

diff --git a/docs/advanced/insights/27-freestyle-or-abap2ui5.md b/docs/advanced/insights/27-freestyle-or-abap2ui5.md
@@ -1,4 +1,4 @@
-# UI5 Freestyle or abap2UI5 — When to Use Which
+# #27 UI5 Freestyle or abap2UI5 — When to Use Which
 
 Both give full access to the UI5 control library. Neither limits what a screen
 can contain. So the choice is not about what is possible — it is about where the

diff --git a/docs/advanced/insights/28-low-code-or-abap2ui5.md b/docs/advanced/insights/28-low-code-or-abap2ui5.md
@@ -1,4 +1,4 @@
-# Low-Code or abap2UI5 — When to Use Which
+# #28 Low-Code or abap2UI5 — When to Use Which
 
 A commercial low-code platform and abap2UI5 answer the same question: modern
 UIs for SAP systems without a full frontend stack per app. The models could