Skip to content

Commit 3c95a16

Browse files
oblomov-devoblomov-dev
authored
Update concept.md
1 parent 303f6d3 commit 3c95a16

File tree

1 file changed

+128
-26
lines changed

1 file changed

+128
-26
lines changed

‎docs/advanced/technical/concept.md‎

Lines changed: 128 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,130 @@
11
# Key Concept: UI5 Over-the-Wire?
22

3+
This article provides a technical dive into abap2UI5, a framework that simplifies SAP UI5 application development by moving both UI rendering and logic back to the ABAP backend. It introduces the key architectural concept — HTML Over the Wire — and explains how this idea is adapted to the SAP ecosystem.
4+
5+
6+
##### What is HTML Over-the-Wire?
7+
8+
HTML Over the Wire refers to a web architecture where the server renders ready-to-use HTML and sends it directly to the browser. Instead of sending raw data (e.g., JSON) and rendering UIs with JavaScript frameworks on the client, the server handles both the application logic and HTML generation and sending it to the browser — without relying on JSON, client-side MVC frameworks, bundling, or transpiling pipelines.
9+
10+
> You can write fast, modern, responsive web applications by generating your HTML on the server, and delivering that directly to the browser. You don’t need JSON as an in-between format. You don’t need client-side MVC frameworks. You don’t need complicated bundling and transpiling pipelines. [...]
11+
> This is what HTML Over The Wire is all about. It’s a celebration of the simplicity in HTML as the format for carrying data and presentation together, whether this is delivered on the first load or with subsequent dynamic updates.
12+
13+
Unlike Single Page Applications (SPAs), which shift most responsibilities to the browser, HTML Over the Wire maintains control on the backend. UI updates are performed by sending partial HTML fragments over AJAX, which the browser inserts without full page reloads.
14+
15+
<img width="400" alt="image" src="https://github.com/user-attachments/assets/a9fde24a-c572-4e5c-b203-59a0667b9931" />
16+
17+
_HTML "Over the Wire" Lifecycle [(Quelle)](https://community.sap.com/t5/technology-blog-posts-by-members/fiori-like-web-app-development-in-pure-abap-with-htmx-and-fundamental/ba-p/13500763)_
18+
19+
#### Where does it come from?
20+
21+
In early web development, **Server-Side Rendering (SSR)** was the default. Every user action triggered a full-page reload with a complete HTML response.
22+
23+
The rise of **Single Page Applications (SPAs)** shifted rendering to the browser. SPAs fetch raw data (often via OData in SAP) and dynamically build UIs with JavaScript frameworks like React, Angular, Vue, or, in the SAP world, UI5.
24+
25+
However, SPAs introduced new challenges:
26+
- API layers and data contracts
27+
- Separate frontend-backend development workflows
28+
- Complex build and deployment pipelines
29+
30+
As a reaction, the **Over-the-Wire** paradigm re-emerged:
31+
- Servers send UI fragments, not full pages
32+
- Browsers update only specific parts of the page
33+
- Frontends stay simple and declarative
34+
35+
Architectural Comparison:
36+
37+
| Approach | Data Flow | Rendering Location | Period |
38+
|---------------|----------------------------------|---------------------------|------------------|
39+
| **SSR** | Full-page HTML responses | Entirely on the server | 1990s – 2010s |
40+
| **SPA** | Raw data (JSON), client builds UI| Client-side (JavaScript) | 2010s – today |
41+
| **Over-the-Wire** | HTML fragments for partial updates | Server renders, browser inserts | 2020s (re-emerging) |
42+
43+
Several frameworks successfully implement the HTML Over-the-Wire approach:
44+
45+
| Framework | Focus | Tech Stack |
46+
|-----------------------|--------------------------------------|----------------------|
47+
| [htmx](https://htmx.org) | Progressive enhancement via HTML partials | Any web stack |
48+
| [Hotwire (Turbo)](https://hotwired.dev) | HTML-over-the-wire for Rails apps | Ruby on Rails |
49+
| [Phoenix LiveView](https://hexdocs.pm/phoenix_live_view) | Real-time UI with server rendering | Elixir / Phoenix |
50+
| [Livewire](https://livewire.laravel.com) | Server-driven UI components in PHP | Laravel / PHP |
51+
| [Unpoly](https://unpoly.com) | Simplified partial page updates | Any web stack |
52+
53+
54+
#### How can we adapt this to UI5?
55+
56+
UI5 applications typically follow an SPA architecture. The backend delivers data via OData, while all logic and UI rendering occur on the frontend. But one specific characteristic we should examine closely is how the UI5 framework creates views. Each HTML output is rendered from an XML-View (let's ignore the former HTML/JS/JSON-Views), with its associated data from the server. The view is stored at the frontend as part of the app:
57+
58+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/3b2a884e-e899-4b60-8a95-79b418f33657" />
59+
UI5 normally - ABAP delivers only Data
60+
61+
abap2UI5 introduces a pivotal change: the backend also sends the view. This shifts the frontend’s role towards an HDA, displaying views and data received from the server:
62+
63+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/9717f500-c0de-4428-a996-11fc131c073c" />
64+
65+
"UI5 Over the Wire" - ABAP delivers Data & View together
66+
67+
Despite still relying on frontend HTML rendering, all necessary information (view & data) is now retrieved via AJAX from the backend. As a result, the UI5 app remains a SPA, but its role is now reduced to that of a HDA, which is responsible solely for displaying the view and its data:
68+
69+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/17a3a301-b698-4704-9cbc-43798c5bd600" />
70+
71+
UI5 app downgraded to an HDA - Displaying Data & View received from the server
72+
73+
This means that the frontend app is not aware of what it is currently displaying (whether it's a table, list or input) and neither is it aware of what actions will be taken next. The app logic remains completely on the server and the frontend app is just a small HDA transmitted with the first request:
74+
75+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/2c9f8dc1-c6d8-4e93-80a2-b50bfc1d5ec1" />
76+
77+
"UI5 Over the Wire" - Server to Client Communication
78+
79+
The HDA displays the view with its data and sends back each event to the server for determination of the next action and output. This process is somewhat similar to the PAI/PBO process used in former SAP GUI apps:
80+
81+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/3b464d0b-19fd-400c-a7e4-3eec893f7724" />
82+
83+
UI5 vs. "UI5 Over the Wire" - Communication
84+
85+
We use an AJAX roundtrip logic similar to "HTML Over the Wire" approaches, but in this case, we cannot send HTML directly. Instead, we send a View combined with its Data. This results in a concept that we could refer to as "UI5-View Over the Wire".
86+
87+
##### 7. Merging Data & Presentation
88+
89+
A typical "UI5-View Over the Wire" response looks like this:
90+
91+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/d52112e6-b9b7-4e7f-ac7f-825c20620240" />
92+
93+
"UI5 Over the Wire" - Response with View & Data together
94+
95+
96+
97+
98+
99+
100+
101+
102+
103+
104+
105+
106+
107+
108+
109+
110+
111+
112+
113+
114+
But is this maybe just the same like RAP, but in a different format?
115+
116+
117+
118+
119+
120+
121+
122+
123+
124+
125+
126+
This pattern has gained popularity through frameworks like htmx, Hotwire, Phoenix LiveView, and Laravel Livewire. They aim to simplify development, reduce dependencies, and return to server-driven UIs.
127+
3128

4129
This article provides a technical deep dive into **abap2UI5**. It is aimed at developers who want to understand how abap2UI5 works "under the hood" and how it simplifies UI5 development by keeping both logic and UI generation on the backend.
5130

@@ -9,9 +134,9 @@ It covers the core ideas behind the framework — including its architecture, co
9134

10135
One of the core ideas behind abap2UI5 is inspired by the concept of **"HTML Over the Wire"**. This approach suggests rendering HTML directly on the server and sending it to the browser — without relying on JSON, client-side MVC frameworks, bundling, or transpiling pipelines.
11136

12-
> You can write fast, modern, responsive web applications by generating your HTML on the server, and delivering that directly to the browser. You don’t need JSON as an in-between format. You don’t need client-side MVC frameworks. You don’t need complicated bundling and transpiling pipelines. But you do need to think different. [...]
13137

14-
> This is what HTML Over The Wire is all about. It’s a celebration of the simplicity in HTML as the format for carrying data and presentation together, whether this is delivered on the first load or with subsequent dynamic updates.
138+
139+
15140

16141
The idea was introduced in the SAP community through examples using the JavaScript library **htmx** to build Fiori-like apps. Unlike typical Single Page Applications (SPAs), where state and logic reside on the frontend, the **HTML Over the Wire** principle keeps all application logic and state on the server.
17142

@@ -98,29 +223,6 @@ Flow:
98223

99224
While popular frameworks like Hotwire, Livewire, and Phoenix LiveView follow this approach, **abap2UI5 adapts it to SAP’s technological environment**, using SAP UI5 for frontend rendering and ABAP for backend-driven UI definitions.
100225

101-
#### History
102-
103-
In early web development, **Server-Side Rendering (SSR)** was the default. Every user action triggered a full-page reload with a complete HTML response.
104-
105-
The rise of **Single Page Applications (SPAs)** shifted rendering to the browser. SPAs fetch raw data (often via OData in SAP) and dynamically build UIs with JavaScript frameworks like React, Angular, Vue, or, in the SAP world, UI5.
106-
107-
However, SPAs introduced new challenges:
108-
- API layers and data contracts
109-
- Separate frontend-backend development workflows
110-
- Complex build and deployment pipelines
111-
112-
As a reaction, the **Over-the-Wire** paradigm re-emerged:
113-
- Servers send UI fragments, not full pages
114-
- Browsers update only specific parts of the page
115-
- Frontends stay simple and declarative
116-
117-
Architectural Comparison:
118-
119-
| Approach | Data Flow | Rendering Location | Period |
120-
|---------------|----------------------------------|---------------------------|------------------|
121-
| **SSR** | Full-page HTML responses | Entirely on the server | 1990s – 2010s |
122-
| **SPA** | Raw data (JSON), client builds UI| Client-side (JavaScript) | 2010s – today |
123-
| **Over-the-Wire** | HTML fragments for partial updates | Server renders, browser inserts | 2020s (re-emerging) |
124226

125227
#### Frameworks
126228

@@ -224,4 +326,4 @@ For typical enterprise apps — forms, dashboards, transactions — abap2UI5 off
224326
**Further Reading:**
225327
- [htmx in a nutshell](https://htmx.org/docs/#introduction)
226328
- [HTML Over the Wire](https://signalvnoise.com/svn3/html-over-the-wire/)
227-
- [Fiori-like web app development in pure ABAP with htmx and Fundamental](https://community.sap.com/t5/technology-blog-posts-by-members/fiori-like-web-app-development-in-pure-abap-with-htmx-and-fundamental/ba-p/13500763)
329+
- [Fiori-like web app development in pure ABAP with htmx and Fundamental](https://community.sap.com/t5/technology-blog-posts-by-members/fiori-like-web-app-development-in-pure-abap-with-htmx-and-fundamental/ba-p/13500763)

0 commit comments

Comments
 (0)