Skip to content

Commit 0da1c78

Browse files
authored
Update concept.md
1 parent 552221d commit 0da1c78

File tree

1 file changed

+14
-14
lines changed

1 file changed

+14
-14
lines changed

docs/technical/concept.md

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -22,7 +22,7 @@ In this architecture the initial request delivers JavaScript and CSS, Subsequent
2222

2323
This results in a clean and lightweight frontend — a pure rendering layer — while all logic remains under full control of the backend.
2424

25-
Several modern frameworks follow this pattern:
25+
Several modern frameworks adopt this pattern:
2626
* [htmx](https://htmx.org) Progressive enhancement via HTML partials (Any web stack)
2727
* [Hotwire (Turbo)](https://hotwired.dev) HTML-over-the-wire for Rails apps (Ruby on Rails)
2828
* [Phoenix LiveView](https://hexdocs.pm/phoenix_live_view) Real-time UI with server rendering (Elixir/Phoenix)
@@ -57,21 +57,21 @@ UI5 freestyle apps follow the Single Page Application model. All UI artifacts ar
5757
<p align="center">
5858
<img width="500" alt="image" src="https://github.com/user-attachments/assets/8043d0d9-5852-4dac-aefb-37ec8d6e66be" />
5959
<br/>
60-
<em>UI5 Freestyle - UI is built on the client; backend delivers only Data via OData</em>
60+
<em>UI5 freestyle - UI is built on the client; backend delivers only Data via OData</em>
6161
</p>
6262

6363
Since UI5 is a client-side rendering framework, the HTML output cannot be generated on the backend and sent to the client. Instead, HTML is produced in the browser using the UI5 framework and its built-in render.
6464

6565
#### Sending Views from Backend
6666

67-
But how can we still generate SAP UI5 views from the backend?
67+
But how can we generated UI5 HTML in the backend?
6868

69-
Fortunately, UI5 has a defining characteristic that allows us to shift part of the view generation to the backend. In UI5 Freestyle apps, each view is defined in XML — the so-called UI5 XML View. The UI5 framework uses this XML definition, combined with data from the backend, to render HTML in the browser.
69+
Fortunately, UI5 has a defining characteristic that allows us to shift part of the view generation to the backend. In UI5 freestyle apps, each view is defined in XML — the so-called UI5 XML View. The UI5 framework uses this XML definition, combined with data from the backend, to render HTML in the browser.
7070

7171
<p align="center">
7272
<img width="400" alt="image" src="https://github.com/user-attachments/assets/1ae233c6-96ff-4370-ac31-30705c18a0f7" />
7373
<br/>
74-
<em>UI5 Freestyle – HTML rendered in browser based on Frontend XML View and Backend Data</em>
74+
<em>UI5 freestyle – HTML rendered in browser based on frontend XML View and backend Data</em>
7575
</p>
7676

7777
abap2UI5 introduces now a subtle but important shift: what if the backend also delivers the XML View?
@@ -81,7 +81,7 @@ While HTML rendering still happens on the frontend, both the view definition and
8181
<p align="center">
8282
<img width="400" alt="image" src="https://github.com/user-attachments/assets/7886d77e-acef-4e96-bc0f-ed3728e06358" />
8383
<br/>
84-
<em>abap2UI5 – HTML rendered in browser based on XML View and Data, both send from the Backend</em>
84+
<em>abap2UI5 – HTML rendered in browser based on XML View and Data, both sent from the backend</em>
8585
</p>
8686

8787
The UI5 application remains a single-page application (SPA), but its role changes: it becomes a pure rendering engine for server-defined views and data.
@@ -90,7 +90,7 @@ The UI5 application remains a single-page application (SPA), but its role change
9090

9191
How can user interaction be handled in this architecture?
9292

93-
To enable user interaction, a minimal and static UI5 Freestyle app is delivered with the initial HTTP request. This app contains just enough logic to forward frontend events and typically acts as a shell application. The interaction model is inspired by the classic PAI/PBO pattern known from SAP GUI applications.
93+
To enable user interaction, a minimal and static UI5 freestyle app is delivered with the initial HTTP request. This app contains just enough logic to forward frontend events and typically acts as a shell application. The interaction model is inspired by the classic PAI/PBO pattern known from SAP GUI applications.
9494

9595
When a user triggers an event (e.g., pressing a button), the event information is sent to the backend, where an ABAP class determines what happens next. All logic is executed entirely on the server:
9696

@@ -100,12 +100,12 @@ When a user triggers an event (e.g., pressing a button), the event information i
100100
<em>abap2UI5 – Simple shell app, backend handles all logic</em>
101101
</p>
102102

103-
In standard UI5 Freestyle applications, each app requires its own dedicated set of frontend artifacts:
103+
In standard UI5 freestyle applications, each app requires its own dedicated set of frontend artifacts:
104104

105105
<p align="center">
106106
<img width="350" alt="image" src="https://github.com/user-attachments/assets/abfe4163-e75d-4eab-ad4c-621f693fa6c3" />
107107
<br/>
108-
<em>UI5 Freestyle – Each application requires its own set of deployed UI and App artifacts</em>
108+
<em>UI5 freestyle – Each application requires its own set of deployed UI and App artifacts</em>
109109
</p>
110110

111111
With abap2UI5, the frontend becomes a static UI5 shell shared across all applications. Views and logic are fully defined and maintained in the backend. Each application is represented by a single ABAP class that generates the view and handles events:
@@ -124,7 +124,7 @@ So far, we’ve seen how to display data and handle events using a backend-drive
124124

125125
If we continued relying on OData, updates would typically be routed into the OData service layer — bypassing the ABAP class that also defines the view and handles events in abap2UI5.
126126

127-
Let’s take a closer look at a key UI5 feature: the concept of view models. In UI5 Freestyle, view models are used to bind attributes such as visible or enabled — allowing control properties in the view to be mapped precisely to model attributes:
127+
Let’s take a closer look at a key UI5 feature: the concept of view models. In UI5 freestyle, view models are used to bind attributes such as visible or enabled — allowing control properties in the view to be mapped precisely to model attributes:
128128

129129
<p align="center">
130130
<img width="350" alt="image" src="https://github.com/user-attachments/assets/7eaa09d3-e3f7-4ebb-997d-fc68cc68421f" />
@@ -142,7 +142,7 @@ This leads to the second key architectural shift in abap2UI5: Instead of binding
142142

143143
This means CDS Views and OData services are no longer consumed directly on the frontend. Instead, the complete UI state — both view and model — is sent from the backend in a single response. Any user changes in the UI are then returned to the backend via a lightweight AJAX call containing the updated view model — no OData routing involved.
144144

145-
Developers do not need to manually configure models or bindings. abap2UI5 handles this internally. All that’s required is to expose class attributes via a simple binding method — the framework takes care of the rest.
145+
Developers do not need to manually configure models or bindings. abap2UI5 handles this internally. All that’s required is to expose class attributes using a simple bind method — abap2UI5 handles the rest.
146146

147147
A typical backend response includes both the XML View:
148148

@@ -174,7 +174,7 @@ And its corresponding View Model:
174174
```
175175
#### Application Flow
176176

177-
The overall application flow finally looks like this:
177+
The overall application flow looks like this:
178178

179179
<p align="center">
180180
<img width="600" alt="image" src="https://github.com/user-attachments/assets/f4df9291-c067-495f-bb52-a68e165e15c1" />
@@ -222,7 +222,7 @@ The illustration below shows the difference between a full re-render and a targe
222222
<p align="center">
223223
<img src="https://github.com/user-attachments/assets/79a8c531-b9a0-4bf4-bb1c-7d9019ef8707" width="500" />
224224
<br/>
225-
<em>Partly HTML Rerendering via View Model Updates - Only relevant DOM parts are rerenderd, preserving UI state</em>
225+
<em>Partly HTML Rerendering via View Model Updates - Only relevant DOM parts are re-rendered, preserving UI state</em>
226226
</p>
227227

228228
Thanks to UI5’s powerful data binding mechanism, only the modified DOM elements are updated. This preserves the current UI state — such as input focus — and ensures a smooth, uninterrupted user experience. The XML View and View Model concept make UI5 a perfect team player for the UI5 Over-the-Wire approach combining the strengths of ABAP and UI5 — without the complexity of full client-side re-renders.
@@ -232,7 +232,7 @@ Thanks to UI5’s powerful data binding mechanism, only the modified DOM element
232232
abap2UI5 brings the simplicity and efficiency of the HTML Over-the-Wire pattern into the ABAP ecosystem — combining proven technologies with a smart UI rendering strategy.
233233

234234
Key Benefits:
235-
- Static UI5 Frontend Shell App: Delivered with the initial HTTP GET request; generic and consistent across all apps
235+
- One Static UI5 Shell App: Delivered with the initial HTTP Get request; shared and consistent across all applications
236236
- Backend-Driven UI Control: UI definitions and business logic are implemented entirely in ABAP classes
237237
- ABAP-Centric Development: Eliminates the need for additional JavaScript or dedicated frontend development
238238
- Simplified Deployment Model: No SPA-specific tooling or build processes; application logic and artifacts are maintained via abapGit and standard transport mechanisms

0 commit comments

Comments
 (0)