You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<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>
61
61
</p>
62
62
63
63
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.
64
64
65
65
#### Sending Views from Backend
66
66
67
-
But how can we still generate SAP UI5 views from the backend?
67
+
But how can we generated UI5 HTML in the backend?
68
68
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.
<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>
85
85
</p>
86
86
87
87
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
90
90
91
91
How can user interaction be handled in this architecture?
92
92
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.
94
94
95
95
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:
96
96
@@ -100,12 +100,12 @@ When a user triggers an event (e.g., pressing a button), the event information i
100
100
<em>abap2UI5 – Simple shell app, backend handles all logic</em>
101
101
</p>
102
102
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:
<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>
109
109
</p>
110
110
111
111
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
124
124
125
125
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.
126
126
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:
@@ -142,7 +142,7 @@ This leads to the second key architectural shift in abap2UI5: Instead of binding
142
142
143
143
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.
144
144
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.
146
146
147
147
A typical backend response includes both the XML View:
148
148
@@ -174,7 +174,7 @@ And its corresponding View Model:
174
174
```
175
175
#### Application Flow
176
176
177
-
The overall application flow finally looks like this:
<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>
226
226
</p>
227
227
228
228
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
232
232
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.
233
233
234
234
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
236
236
- Backend-Driven UI Control: UI definitions and business logic are implemented entirely in ABAP classes
237
237
- ABAP-Centric Development: Eliminates the need for additional JavaScript or dedicated frontend development
238
238
- 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