This feature enables developers not only to define the model at Design time, but also to define the model at runtime.
The user doesn't need to do any extra work because abap2UI5 handles the whole process in the background during each AJAX request:
In the application, we can now use RTTI again, in a similar way to how ALV is used. This means there is no need to create separate applications for each model.
The image below is an example with a view including table output showing generic tables whose types are created and modified at runtime (similar to SE16):
Like using RTTI to create a Model, the views in ABAP2UI5 also support RTTI.
In RAP, some predefined control properties can only be modified at runtime, while views are previously defined in CDS artifacts using UI annotations. However, in an abap2UI5 application, the entire view control can be replaced dynamically.
For example, in the following app, a table control is replaced with a list control and vice versa:
Here is the list control:
Here is the form control:
Finally, views and models are defined independently of HTTP services, and we are no longer forced to provide a predefined static OData service for each application, as is the case in RAP. The number of backend artifacts is significantly reduced:
So far we have observed that the abap2UI5 front-end application is not aware of the specific application, just like the generic HTTP service on the server, it is also unaware of the specific models and views it is transferring.
The only non-generic part of this concept is the user application implementing the interface z2ui5_if_app:
In this architecture, the application has complete freedom in creating views and models, but it must also take full responsibility for everything else. The application has to handle program logic, application state, and remember where it came from and where it is going next. All of this is concentrated in this single application layer.