この機能により、開発者は設計時にモデルを定義するだけでなく、実行時にもモデルを定義できるようになります。
abap2UI5 は各 AJAX リクエスト中にプロセス全体をバックグラウンドで処理するため、ユーザーは追加の作業を行う必要はありません。
アプリケーションでは、ALV の使用方法と同様の方法で、RTTI を再度使用できるようになりました。つまり、モデルごとに個別のアプリケーションを作成する必要はありません。
以下の画像は、実行時にタイプが作成および変更される汎用テーブルを示すテーブル出力を含むビューの例です (SE16 と同様)。
RTTI を使用してモデルを作成するのと同様、ABAP2UI5 のビューも RTTI をサポートします。
RAP では、一部の事前定義されたコントロール プロパティは実行時にのみ変更できますが、ビューは UI 注釈を使用して CDS アーティファクトで事前に定義されています。ただし、abap2UI5 アプリケーションでは、ビュー コントロール全体を動的に置き換えることができます。
たとえば、次のアプリでは、テーブル コントロールがリスト コントロールに置き換えられ、その逆も同様です。
リストコントロールは次のとおりです。
フォームコントロールは次のとおりです。
最後に、ビューとモデルは HTTP サービスとは独立して定義されるため、RAP の場合のように、アプリケーションごとに事前定義された静的 OData サービスを提供する必要がなくなりました。バックエンドのアーティファクトの数が大幅に減少します。
これまでのところ、abap2UI5 フロントエンド アプリケーションは特定のアプリケーションを認識しておらず、サーバー上の汎用 HTTP サービスと同様に、転送している特定のモデルやビューも認識していないことがわかりました。
この概念の唯一の非汎用部分は、インターフェイス z2ui5_if_app を実装するユーザー アプリケーションです。
このアーキテクチャでは、アプリケーションはビューとモデルを完全に自由に作成できますが、それ以外のすべてについてもすべての責任を負わなければなりません。アプリケーションは、プログラム ロジック、アプリケーションの状態を処理し、それがどこから来て、次にどこへ行くのかを記憶する必要があります。これらすべてがこの単一のアプリケーション層に集中しています。