正如我上次承诺的那样，我计划浏览该平台的某些功能，这些功能我认为非常有价值。 所以我将在这里做一些系列。 从明显的用户界面，过滤，安全性到一些高级功能（如Web Portal，可扩展性，审核，动态属性等）开始。

CUBA功能＃1 –通用过滤器

我想在这篇博客文章中介绍通用过滤器解决方案。 但是在弄清技术细节之前，让我们开始研究此功能解决的基本用例。

用户如何获得实际需要的数据

我们将继续使用上次的示例：

基于此实体模型，让我们考虑用户可能具有的一些可能的过滤器要求。

首先，在实体本身及其直接属性上有某些过滤器：

• 显示纽约的所有客户
• 显示2015年的所有订单
• 显示价格最低的所有产品。 350 $
• 显示处于“已完成”状态的所有订单

接下来，我们基于1：1 / N：1关联进行过滤：

• 列出客户“ Mario David”的所有订单
• 列出居住在达拉斯的所有客户（通过地址实体）
• 显示“笔记本”类别中的所有产品

然后，我们有了基于1：N / M：N关系的过滤器：

• 列出2015年至少有一个订单的所有客户
• 列出最多包含五个订单项的所有订单
• 列出所有订单项的价格总和大于200 $的订单

基本上，这是过滤器要求的类别，可以满足大约80％的用例。

解决这类问题的程序化方式

我通常处理此类要求的方式如下：首先，我将开始着手研究用户实际希望通过此过滤实现的目标。 通常，它仅用于减少当前执行的工作流的实体实例数量。 例如，“仅针对未及时付款的订单进行过滤” –在这种情况下，工作流程将类似于“发送过期通知”。 使用过滤的另一种方法是，如果结果是报告的基础（本博客文章中未介绍）。

无论是什么原因，当我知道过滤条件是什么时，对我来说，作为程序员的一个简单解决方案就是立即实施过滤条件。 如果我们考虑在Grails中实现，那么我会在后端想到这样的东西：

class OrderController {//...Date now = new Date()respond Order.where { dueDate > now }.list(params)//...
}

这将以简化的方式完成这项工作。 在前端，可以使用下拉框或切换按钮。 另一种可能性是通过链接获取该数据，从而将信息保留在其中。

无论采用哪种实现方式–整个解决方案的重点是，作为开发人员，我必须事先了解此过滤器要求，因为必须以编程方式进行实施。

这些问题的通用解决方案

除了按需直接实施过滤器解决方案外，一种更通用的解决方案也很普遍。 在这种情况下，开发人员不预先知道过滤器要求，而是让用户决定要搜索/过滤的内容。 为此，必须从属性的基础数据类型推断出可能的过滤条件。

可以将此模型视为类似于excel 过滤机制。 excel根据当前列的数据类型，提供在这种情况下有意义的过滤器可能性。 可以将日期过滤到一定范围内，数字必须大于给定数字，字符串可以包含某个子字符串，依此类推。 由于Excel并不真正了解实体和关系，因此无法搜索/过滤关联。 因此，此过滤器机制仅在一定程度上有价值。

CUBA带来了什么

因此，CUBA来到这里，告诉我们，其中有一个“通用过滤器”，它使我们可以过滤大多数我们想要的子数据。 让我们更深入地了解它。

我创建了一个演示应用程序 ，该应用程序是上述域模型的实现。 在这里，我们看到了我们商店中可用的产品列表。 在数据表的顶部，您会注意到过滤器部分，可用于定义该表的过滤器。 链接“添加搜索条件”将查看基础实体（在本例中为Product）并显示所有实体。 实际上，不仅显示了实体的直接属性，而且还显示了相关实体及其属性（以及相关实体及其属性以及……）。

选择一些可用属性后，表中的过滤器部分将填充相应的条件框。 根据属性类型，定义条件的可能性会有所不同。

这是过滤条件的这种组合的一个示例：

根据属性类型，过滤条件可以处于不同的模式。 文本属性可能以给定文本开头或包含给定文本，依此类推。 可以使用相应的日期过滤器来过滤日期，例如在给定日期之前或之后 。 枚举以及“多对一”关联可以通过下拉列表选择。 这种类型的条件模式是set ， list ， =等。我可以继续描述不同的数据类型及其过滤器模式，但现在我将其保留。 如果您想了解所有可能性，请在此处找到一个不错的文档。

我现在展示的内容几乎只是CUBA为用户和开发人员提供有关过滤的可能性的表面。 但是，在考虑时，它具有相当多的功能，可以使用户自行进行过滤。

如您所见，乍看之下，几乎没有什么阻止我（作为开发人员）让用户决定所需的过滤器可能性，而不必手动实现不同的可能性。

要完成这项工作，我需要做什么？

好的，所以有趣的问题可能是，作为开发人员实施此功能需要付出多少努力。 要查看此内容，您必须查看产品列表的UI定义文件 。 基本上它是这样的：

<filter id="filter" datasource="productsDs"><properties include=".*"/>
</filter>

就是这样 。 其实不是，因为你必须做定义productsDs数据源定义，你会在找到XML描述为好。

更精确地说，您通常不会自己编写定义。 相反，您将使用CUBA Studio进行管道。

在这种情况下，您将启动本地Studio安装（并从示例项目中进行git clone），打开该项目，查看您的产品实体（如上所述），并告诉它为其生成标准视图。 在回答了有关此生成步骤的不同选项的几个问题之后，它将为该实体的列表视图提供确切的XML描述符文件，包括过滤器的可能性。

真正的重物是什么？

看到这一点之后，我想到了两件事。 首先，这只是用于特定的过滤方案。 如何预定义此过滤器，以使我的用户不必一遍又一遍地自行挑选它们？ 第二件事是，通常存在过滤要求，这些要求超出了所描述的可能性。 CUBA如何解决？

该平台提供了针对这些异议的解决方案。 在本系列的下一部分中，我将对此进行介绍。

翻译自: https://www.javacodegeeks.com/2015/12/the-generic-filter-in-cuba-platform-excel-filters-on-steroids.html