规避查询页面大小限制

Circumventing query page size limitations

Project Tracker template 中有一个功能可以显示某个项目的项目的统计信息。您可以筛选项目项,但统计信息只会显示所有项目项的统计信息,即筛选器不会影响统计信息。

我想在我的类似实现中添加影响这些统计信息的过滤器功能。我当前的解决方案将这些项目项的键(也受过滤器影响)传递给计算数据源,然后计算数据源使用这些项键计算统计信息,本质上是应用页面中使用的过滤器。

我的问题是我的计算受到查询页面大小的限制。例如,如果我应用将项目数限制为 15 条记录的过滤器,但页面大小为 10 条记录,我将只有前 10 条项目的统计信息,这是没有用的。我需要统计过滤后留下的所有记录。

解决此问题的一种方法是去掉查询页面大小并将其保留为 0。但是,与项目跟踪器模板类似,我在页面上以 table,如果我这样做,页面会变得太重。

如何绕过查询页面大小?我想我可以

这两种方法我都能想到,但我似乎无法实现。我不知道如何隐藏 UI 中的项目以减轻它的重量,因为查询页面大小几乎可以做到这一点。我也尝试过将过滤器从数据源复制到类似的数据源,但这似乎不起作用。

编辑:我可能自己想出了一个方法来解决这个问题,但我仍然需要实施它。现在,我正在使用页面大小受限的项目 Ds 来应用过滤器,并且统计信息是从该数据源构建的。如果相反,我使用一个名为 AllItems 的不受限制的 Ds,并在其上应用过滤器,然后将项目键传递给页面大小受限的 Ds(以显示 UI 中的项目)和计算的 Ds(用于统计)。确认有效后会回复。

我自己解决了这个问题。

为了生成(可刷新的)受过滤但不受页面大小限制的统计信息,我使用了以下数据源结构:

在此结构中,过滤器实际上流向下面的数据源,因为它们被传递给适合过滤器的 ItemKey。这完成的是我的统计数据(用于饼图等)可以动态过滤并考虑所有适合过滤器的记录,而 UI 不会因为使用的数据源而拥挤在太多记录上在 UI 中有查询页面大小限制。