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/technical/concept.md
+6-4Lines changed: 6 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -102,15 +102,17 @@ When a user triggers an event (e.g., pressing a button), the event information i
102
102
<em>abap2UI5 – Simple shell app, backend handles all logic</em>
103
103
</p>
104
104
105
-
As a result, the frontend becomes a static UI5 shell shared across all applications. Views and logic are fully defined and maintained in the backend and each application is represented by backend ABAP class that generates the view and handles events. Every UI5 app becomes a complete ABAP backend project managed through abapGit — eliminating the need for separate frontend deployments entirely:
105
+
The frontend becomes a static app shared across all applications. Views and logic are fully defined and maintained in the backend and each application is represented by backend ABAP classes only. As a result, every UI5 app becomes a complete ABAP backend project — eliminating the need for separate frontend deployments entirely:
106
+
107
+
The frontend becomes a static shell shared across all applications. Views and logic are fully defined and maintained in the backend, and each application is represented solely by backend ABAP classes. As a result, every UI5 development project becomes a complete backend project — eliminating the need for separate frontend deployments entirely:
@@ -134,7 +136,7 @@ Let’s take a closer look at a key UI5 feature: the concept of view models. In
134
136
<em>UI5 View Model Concept – UI control properties are bound to View Model attributes</em>
135
137
</p>
136
138
137
-
This leads to the second subtle shift in abap2UI5: Instead of binding Views to OData, abap2UI5 uses a custom view model created entirely in the backend. This model is constructed dynamically after each request — tailored specifically to the current view — and is sent together with the view definition to the frontend:
139
+
This leads to the second subtle shift in abap2UI5: Instead of binding OData to View, abap2UI5 uses a custom view model created entirely in the backend. This model is constructed dynamically after each request — tailored specifically to the current view — and is sent together with the view definition to the frontend:
@@ -144,7 +146,7 @@ This leads to the second subtle shift in abap2UI5: Instead of binding Views to O
144
146
145
147
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.
146
148
147
-
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.
149
+
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.
148
150
149
151
A typical backend response includes both the XML View:
0 commit comments