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
Copy file name to clipboardExpand all lines: docs/advanced/technical/concept.md
+40-29Lines changed: 40 additions & 29 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,69 +53,83 @@ Architectural Comparison:
53
53
|**Over-the-Wire**| HTML fragments for partial updates | Server renders, browser inserts | 2020s (re-emerging) |
54
54
55
55
56
-
#### How works UI5?
56
+
#### How Does UI5 work?
57
57
58
-
UI5 freestyle apps follow the SPA model. All rtifacts are stored at the frontend and the backend supplies data through OData, while all rendering and logic execution occur in the browser:
58
+
UI5 freestyle apps follow the Single Page Application (SPA) model. All UI artifacts are stored on the frontend, while the backend provides data via OData. Both rendering and logic execution occur entirely in the browser.
Because UI5 is a client-side rendering framework, the HTML cannot be generated on the backend and sent to the client. The html needs to necessarily generated at the frontend in Javascript.
67
+
65
68
66
-
As we need UI5 for rendering the HTML and it is a client side framework we are limited here, we can not build HTML in the backend and send it from there. But there is a defining feature of UI5 and its use of XML views to generate HTML. These views reside on the frontend and are populated with server JSON data. XML-Views and JSON Darta is used by the UI5 framework to generate the HTML at the frontend.
69
+
#### How can we send the View from the backend?
67
70
71
+
Luckily there is a defining feature of UI5 and how it generates HTML which we can use to verlangern the view generation to the backend. Usually every view relies on a xml definition the so called XML View. The ui5 framework used this xml together with the data from the backend an generates the HTML at the frontend:
<em>UI5 Freestyle – HTML is generated from XML View and data sent via OData</em>
77
+
</p>
70
78
71
79
abap2UI5 introduces here the first a small shift: what if the server now also delivers the xml view? The frontend becomes a passive display layer for views and data received from the server:
<em>UI5 Freestyle – HTML is generated from XML View and data sent bot form the server</em>
75
85
</p>
86
+
Although the frontend still renders HTML, all relevant information (view and data) is obtained from the backend via AJAX. The UI5 application technically remains an SPA but now functions solely as a rendering layer for the server-defined UI and Data.
76
87
77
-
"UI5 Over the Wire" - ABAP delivers Data & View
88
+
#### How can we bring the logic to the backend?
78
89
79
-
Although the frontend still renders HTML, all relevant information (view and data) is obtained from the backend via AJAX. The UI5 application technically remains an SPA but now functions solely as a rendering layer for the server-defined UI and Data:
We can now easily add some interaction with putting some static code at the frontend which sends events to the backend, This process resembles the classical PAI/PBO model from SAP GUI applications. The app renders the provided view and data, then returns any triggered events to the backend, which decides what should happen next. The frontend is unaware of the current view (e.g., table, list, input) or the next actions. All logic is handled on the backend. The frontend app is a static UI5 application delivered with the first request:
UI5 app downgraded - Displaying Data & View received from the server
86
95
87
-
The frontend is unaware of the current view (e.g., table, list, input) or the next actions. All logic is handled on the backend. The frontend app is a static UI5 application delivered with the first request:
96
+
with that we get a static logoi containe at the frontend and the backend gets in abap classes the lgoc hadles. every app becomes an abap class no need for frontend apps. Before we had a lot of fronten daritfats:
Now we just use a single dummy app and can store all view and logic at the backend.
91
101
92
-
The app renders the provided view and data, then returns any triggered events to the backend, which decides what should happen next. This process resembles the classical PAI/PBO model from SAP GUI applications:
Communication relies on AJAX roundtrips akin to HTML Over the Wire, but pure HTML cannot be sent since UI5 still requires XML views and JSON models. abap2UI5 leverages UI5's capability to render HTML from these constructs. This results in a model referred to as _UI5-XML-View Over-the-Wire_
106
+
So far we can display data and have a backend driven approach,but how can we get teh data back when someone mackes a change at the frontend, while we still relie on odata, the request would be go into our backen dodata implementtion and not in aour newly abapo classes in the backend which also sends the view.
99
107
100
-
_UI5-XML-View and View-Model over-the-wire_:
101
-
Here is the second shift, abap2UI5 sends a View Model from the bachend. you dont need odata you can also use view models at the frontend, this is used to send it from the backend.
108
+
abap2UI5 sends a View Model from the bachend. in uui cu acan also vie model. ususally they are used to bound atribute (visible/nuvisibe) and they a reused on json models:
102
109
103
-
A typical response in this pattern includes both view and model data:
we can not consume odata or cds directly in the abap layer and only send the view + view model to the frontend. furthermore we can use make tings editable and send it directly to the backend and exchange data.
111
119
120
+
the abap2ui5 framework opffers binding ethods and let the attribute via classes, everyhting is handled in the backgroudn and the app developer does not need to pay attentiojto to that,
112
121
113
122
123
+
A typical response in this pattern includes both view and model data:
A central feature of HTML Over the Wire is that only the affected parts of the page are updated, rather than the entire document. Can this be achieved in UI5? While altering the XML view would typically trigger a full re-render, updating only the view model and binding attributes accordingly allows UI5 to update just the relevant UI elements. Consider this example:
120
134
121
135
```abap
@@ -149,9 +163,6 @@ ENDCLASS.
149
163
client->view_model_update( ).
150
164
```
151
165
152
-
##### Controls
153
-
focus stays the same
154
-
no feature of ui5 its just shows how the ui5 frmaework is doing a beuatiful job watching it partly rerenderig the dom.
155
166
#### What about RAP?
156
167
157
168
Although RAP [(3)](https://pages.community.sap.com/topics/abap/rap) shifts more logic and development to the backend, it cannot be considered an “over-the-wire” approach:
0 commit comments