在真实的应用程序中，界面的入口点经常会被这种界面元素的初始化方法填满。为了避免这个问题，CUBA提供了一个非常有用的注解 @Install。看看使用这个注解怎么避免这个情况：
事实上，这里是将货币控件验证的逻辑代理给了界面的 currencyFieldValidator 方法来执行。虽然看上去稍微复杂一点，但是开发人员使用起这个功能来惊人的快速。
界面Builders/通知消息/对话框CUBA 7 还引入了一些新的非常有用的带有流式 API 的组件：
l ScreenBuilders 结合了流式工厂来生成标准的查找、编辑和自定义界面。下面的例子展示了如何从一个界面打开另一个界面。注意，build() 方法能返回正确类型的界面实例，不需要不安全的类型转换。
l Screens 组件相对于 ScreenBuilders 来说提供了更底层的抽象，用来显示和创建界面。并且提供了访问 CUBA 应用程序中所有已打开界面信息的方法（Screens#getOpenedScreens），如果需要遍历这些界面，这个方法很有用。
l Notifications和Dialogs 组件均提供了自描述的方便接口。这里有个例子创建对话框和消息通知：
CUBA 之所以可以做到后台UI的快速开发，不仅仅是因为提供了可以生成大部分代码的可视化工具，还因为提供了大量开箱即用的具有数据感知能力的组件。 这些组件只需要知道要使用哪些数据，其余事情会自动管理。例如， 查找列表、选择器字段、具有 CRUD 操作的各种网格等。
在版本 7 之前，数据绑定是通过称为数据源的对象实现的，数据源包装单个实体或实体集合、与数据感知组件绑定，然后响应数据感知组件的数据变化。 这种方法非常有效，但是是以一个整块的方式实现的。 整块石头似的架构通常在可定制性方面会有问题。因此在 CUBA 7 中，这块坚固的巨石被分成 3 个数据组件：
l Data Loader (数据加载器） 是数据容器的数据提供者。 数据加载器不保存数据，它们只是将所有必需的查询参数传递给数据存储，并将结果数据集提供给数据容器。
l Data container (数据容器) 保留加载的数据（单个实体或多个实体）并以响应式的方式将数据提供给数据感知组件：被包装实体的所有更改都会暴露给相应的UI组件，反之亦然，UI组件内的所有更改都会引起数据容器作出相应更改。
l Data context （数据上下文）是一个强大的数据更改管理器，可跟踪更改并提交所有已修改的实体。 一个实体可以合并到一个数据上下文中，合并后会得到一个原始实体的副本，这个副本与原始实体有一个唯一但非常重要的区别：对副本实体及其引用的所有实体（包括集合）的所有修改都将被跟踪、存储和提交。
数据组件可以在界面描述符中声明，也可以使用专门的工厂类 - DataComponents 以编程的方式创建。
其它上面介绍了新的界面API中最重要的部分，所以剩下的部分我简要列出 Web客户端层中的其他重要功能：
URL 历史记录和导航。此功能解决了在 WEB 浏览器中具带有“后退”按钮的 SPA 应用程序存在的一个普遍问题，提供了一种简单地为应用程序界面分配路径的方法，同时使 API 能够在URL中反映界面的当前状态。
使用 Form 代替 FieldGroup。 FieldGroup 是一个数据感知组件，用于显示和修改单个实体的字段。它在运行时推断出用于显示字段的实际UI组件。也就是说，如果你的实体中有一个日期类型的字段，它将使用 DateField 组件来显示 。但是，如果你希望以编程方式使用此组件，则需要将此组件注入到界面控制器并手动将其转换为正确的类型（在我们的示例中为DateField）。过了一段时间，可能会字段类型更改为其他类型，这时应用程序就是崩溃。表单通过显式声明组件类型解决此问题。关于 Form 的更多信息请参阅这里。