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/test.md
+13-3Lines changed: 13 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,7 +32,7 @@ The first approaches in this direction were introduced back in Phoenix LiveView
32
32
33
33
In the end, all of these concepts share the belief that it's possible to develop apps with much less complexity, but only slightly lower level of UI fidelity compared to SPAs. Or, when we try to illustrate it visually, they aim to find a "sweet spot" between MPAs and SPAs:
Most of my knowledge about this subject comes from this blog posts, and it's still relatively new to me (so I don't consider myself an expert). However, it's fascinating to see the existing frameworks and to contemplate what might be achievable in the future, such as selectively re-rendering specific parts of the view or implementing smoother page transitions. I recommend taking an hour to watch this video, where all of these concepts are presented very well.
@@ -45,29 +45,33 @@ UI5 differs significantly from frameworks like htmx and unpoly. In an UI5 app, a
45
45
46
46
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:
"UI5 Over the Wire" - ABAP delivers Data & View together
57
59
58
60
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:
UI5 app downgraded to an HDA - Displaying Data & View received from the server
63
65
64
66
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:
"UI5 Over the Wire" - Server to Client Communication
68
71
69
72
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:
"UI5 Over the Wire" - Response with View & Data together
82
87
@@ -86,10 +91,11 @@ But is this maybe just the same like RAP, but in a different format?
86
91
87
92
RAP also aims to find a "sweet spot" between a SPA and MPA. I am not certain of the exact approach they use to bring their view and model to the frontend, but they enrich responses either within the JSON itself or within the metadata of the initial OData-Request and the view and the model is defined previously in CDS Views in the backend:
@@ -103,23 +109,27 @@ Overall RAP does not mix View, Model and Logic as radically as the "Over the Wir
103
109
104
110
First, we do not define a specific HTTP-Service for transmitting the View and the Data. Instead, every app uses the same generic HTTP-Handler including two strings (one for the View and one for the Data) eliminating the need to develop individual OData-Services with SEGW or CDS. During runtime the ABAP variables & tables are transformed into a JSON-Model and transmitted as a string to the frontend. In JavaScript it is parsed again into a JSON-Model and binded to the UI5-View:
Data Transfer in abap2UI5 - ABAP variables & tables are automatically synchronized with the UI5-Model
108
115
109
116
Furthermore we not only send the data but also the metadata (Data Model) with every request (7). This is different from classic OData communication, where the metadata is sent with the initial OData request to establish the model at the beginning, and only the data is exchanged afterward. With this approach, we can now send different models with every request:
OData vs. UI5 Over the Wire - Model & Data transfer
113
121
114
122
##### (10) Define Model at Runtime
115
123
116
124
This enables the possibility to define models not only at design time, but also at runtime. The user doesn't have to do any extra work because abap2UI5 handles the entire process in the background during every AJAX request:
In apps we can use RTTI now again in a way that is similar to how it was used with ALVs. This means that there is no need to create separated apps for each model. In this demo, you can see an abap2UI5 app with a view including a table output that displays a generic table and its type is created and modified at runtime (similar to SE16):
0 commit comments