Skip to content

Commit ad54232

Browse files
authored
update
1 parent 4d0c098 commit ad54232

File tree

3 files changed

+137
-1
lines changed

3 files changed

+137
-1
lines changed

docs/.vitepress/config.mjs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -165,7 +165,7 @@ export default defineConfig({
165165
{ text: 'test', collapsed : "true" , items: [
166166
{ text: '___', collapsed : "true" , items: [
167167
{ text: 'Key Concept', link: '/advanced/technical/concept' },
168-
{ text: 'Architecture', link: '/advanced/technical/domain' },
168+
{ text: 'Architecture', link: '/advanced/technical/architecture' },
169169
{ text: 'Development Experience', link: '/advanced/technical/dx' },
170170
{ text: 'Cloud Ready', link: '/advanced/technical/cloud' },
171171
{ text: 'REST', link: '/advanced/technical/rest' },
Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,65 @@
11
# Architecture: UI-Driven-Design?
22

3+
4+
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:
5+
6+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/9717f500-c0de-4428-a996-11fc131c073c" />
7+
8+
"UI5 Over the Wire" - ABAP delivers Data & View together
9+
10+
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:
11+
12+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/17a3a301-b698-4704-9cbc-43798c5bd600" />
13+
14+
UI5 app downgraded to an HDA - Displaying Data & View received from the server
15+
16+
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:
17+
18+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/2c9f8dc1-c6d8-4e93-80a2-b50bfc1d5ec1" />
19+
20+
"UI5 Over the Wire" - Server to Client Communication
21+
22+
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:
23+
24+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/3b464d0b-19fd-400c-a7e4-3eec893f7724" />
25+
26+
UI5 vs. "UI5 Over the Wire" - Communication
27+
28+
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".
29+
30+
##### 7. Merging Data & Presentation
31+
32+
A typical "UI5-View Over the Wire" response looks like this:
33+
34+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/d52112e6-b9b7-4e7f-ac7f-825c20620240" />
35+
36+
"UI5 Over the Wire" - Response with View & Data together
37+
38+
But is this maybe just the same like RAP, but in a different format?
39+
40+
41+
42+
43+
44+
45+
46+
47+
48+
49+
50+
51+
52+
53+
54+
55+
56+
57+
58+
59+
60+
61+
### new
62+
363
Domain-Driven Architecture with RAP (and contrast to UI-Driven)
464

565
**Domain-Driven Design (DDD)** is an architectural approach that models software systems based on real-world business domains. It promotes aligning code with business terminology and processes.

docs/advanced/technical/concept.md

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

3+
4+
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.
5+
6+
It covers the core ideas behind the framework — including its architecture, codebase, and compatibility — and shows how concepts like **"HTML Over the Wire"** are adapted to the ABAP environment, offering a new approach to building UI5 applications.
7+
8+
##### 1. HTML Over the Wire
9+
10+
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.
11+
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. [...]
13+
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.
15+
16+
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.
17+
18+
After the initial page load, only small HTML fragments are sent asynchronously via AJAX to update parts of the page — avoiding full reloads.
19+
20+
<img width="400" alt="image" src="https://github.com/user-attachments/assets/a9fde24a-c572-4e5c-b203-59a0667b9931" />
21+
22+
_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)_
23+
24+
This approach contrasts with the common separation of concerns, where HTML, CSS, and JavaScript are managed independently on the frontend while the backend only delivers data.
25+
26+
##### 2. Hypermedia Driven App
27+
28+
This concept evolves into what is termed a Hypermedia-Driven Application (HDA). In HDAs, the browser focuses solely on rendering HTML, CSS, and JavaScript without knowledge of the application's state. All logic is maintained on the server.
29+
30+
In contrast, SPAs define all routes and actions upfront on the frontend, requiring a full rebuild for any modification. The following illustration compares MPAs, SPAs, and HDAs:
31+
32+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/8117dc10-f0ba-4c52-9d1d-6b9d0986401d" />
33+
34+
MPA vs. SPA vs. HDA [(Quelle)](https://craftcms.com/events/dot-all-2022/sessions/a-practical-guide-to-html-over-the-wire)
35+
36+
37+
##### 3. Rethinking Separation of Concerns
38+
39+
Unlike traditional architectures, HDAs do not prioritize strict separation of CSS, JavaScript, and HTML. The backend generates the UI and handles program flow, much like SAP GUI applications in the past. This centralized approach simplifies customization and maintenance.
40+
41+
##### 4. Dive Deeper
42+
43+
Frameworks like Phoenix LiveView (2018) and Laravel Livewire (2019) were among the first to adopt this principle. Tools like htmx, hotwire, and unpoly followed, aiming to reduce complexity while maintaining high UI fidelity. These frameworks seek a "sweet spot" between SPA and MPA architectures:
44+
45+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/41af4a41-829e-4289-82f5-18ee7408054b" />
46+
"Sweet Spot" between SPA and MPA (Quelle)
47+
48+
A recommended video offers an excellent introduction to these ideas.
49+
50+
##### 5. UI5 Architecture
51+
52+
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:
53+
54+
<img width="600" alt="image" src="https://github.com/user-attachments/assets/3b2a884e-e899-4b60-8a95-79b418f33657" />
55+
56+
UI5 normally - ABAP delivers only Data
57+
58+
59+
60+
61+
62+
63+
64+
65+
66+
67+
68+
69+
70+
71+
72+
73+
74+
75+
76+
77+
#### new
78+
379
The key concept of **abap2UI5** is to apply the **HTML Over-the-Wire** approach to SAP UI5 application development.
480

581
#### Concept

0 commit comments

Comments
 (0)