在当前版本的JHipster(编写本文时为4.10.2)中,实体可以通过实体子生成器启用过滤,或者将过滤器EntityName和服务EntityName与serviceClass一起包含到项目的JDL文件中.这将生成一个Spring项目,其中EntityNameResource类中的getAllEntities()方法采用从URL GET参数构造的Criteria参数.

这与为端点生成的Swagger UI开箱即用,并且此UI发出的查询表明后端期望每个标准采用GET参数键值对的形式;这与the 4.10.2 Filtering docs一致.

但是,我想知道是否有一种预期的方法可以从我错过的前端Angular项目中使用它,除了自己进行适当的修改以构建一致的URL.

前端服务使用静态函数createRequestOption(req)(从app / shared / model / request-util.ts导出)来填充GET参数以进行分页和排序.此函数还期望传入的req对象可能具有查询属性;最初,我认为填充此参数是使用后端过滤的预期方式.

但是,createRequestOption(req)的实现当前将req.query的值放入名为query的GET参数中;即,这不会产生后端预期的查询格式,后者需要每个标准单独的GET参数.

我使用的解决方案是修改createRequestOption(req)以期望一组键值对对象而不是req.query(我称之为req.criteria),并将这些对象添加到URLSearchParams的数组中(它必须是数组,而不是地图,因为可能有多个具有相同键的参数,例如name.in = Megatron& name.in = Optimus).

所以我改变了：

params.set('query',req.query);

至：

if (req.crieria && req.crieria.length > 0) {
    req.criteria.forEach((criterion) => {
        params.append(criterion.key,criterion.value);
    });
}

…使用组件代码按以下行填充数组：

let criteria = [
    {key: 'name.equals',value: 'Optimus'},{key: 'power.equals',value: '10'}
];

this.entityService.query({
    page: this.page - 1,size: this.itemsPerPage,sort: this.sort(),criteria
});

我刚刚在GitLab here中使用这种方法创建了一个实际工作的示例,其中一些表单字段过滤了测试单实体单片应用程序(目前仅等于查询).

所以,我的问题是：

>我是否错过了使用当前JHipster版本执行此操作的预期方式？
> req.query在request-utils.ts的当前实现中的用途是什么？
>这个区域预计会在即将推出的版本中发生变化吗例如,前端搜索字段是否可以按启用ElasticSearch的应用程序的方式自动生成(但对于每个实体属性)？

非常感谢.