共计 642 个字符,预计需要花费 2 分钟才能阅读完成。
这个个性使得开发人员不仅能够在 Design time 时定义模型,而且能够在运行时定义模型。
用户不须要做任何额定的工作,因为 abap2UI5 在每个 AJAX 申请期间在后盾解决整个过程:
在应用程序中,咱们当初能够再次应用 RTTI,其形式与 ALV 的应用形式相似。这意味着无需为每个模型创立独自的应用程序。
下图是一个例子,其视图包含显示通用表的表输入,其类型在运行时创立和批改(相似于 SE16):
同应用 RTTI 创立 Model 一样,ABAP2UI5 里的视图也反对 RTTI.
在 RAP 中,只能在运行时批改某些预约义的管制属性,而视图是在之前应用 UI 正文在 CDS 工件中定义的。然而,在 abap2UI5 应用程序中,能够动静替换整个视图控件。
例如,在以下利用中,表格控件被替换为列表控件,反之亦然:
上面是列表控件:
上面是表格控件:
最初,视图和模型的定义独立于 HTTP 服务,咱们不再被迫为每个应用程序提供预约义的动态 OData 服务,就像 RAP 中的状况一样。后端工件的数量显着缩小:
到目前为止,咱们察看到 abap2UI5 前端应用程序不晓得特定的应用程序,就像服务器上的通用 HTTP 服务一样,它也不晓得它正在传输的特定模型和视图。
这个概念惟一的非通用局部是实现接口 z2ui5_if_app 的用户应用程序:
在这种架构中,应用程序在创立视图和模型方面领有齐全的自在,但它也必须对其余所有承当全副责任。应用程序必须处理程序逻辑、应用程序状态,并记住它来自哪里以及下一步要去哪里。所有这所有都集中在这个繁多的应用程序层中。
正文完