JHipster:使用条件过滤实体-预期的Angular客户端方法 [英] JHipster: Filtering entities with criteria - intended Angular client-side approach

问题描述

我最近开始使用 JHipster -感谢这个出色的项目的维护者！

I've recently started using JHipster - thanks to the maintainers for this fantastic project!

在当前版本的JHipster(撰写本文时为4.10.2)中，实体可以通过实体子生成器或通过将filter EntityName和service EntityName with serviceClass包含到项目的JDL文件中来启用过滤.这将产生一个Spring项目，其中EntityNameResource类中的getAllEntities()方法采用从URL GET参数构造的Criteria自变量.

In the current version of JHipster (4.10.2 at the time of writing), entities can have filtering enabled via the entity sub-generator, or by including filter EntityName and service EntityName with serviceClass to the project's JDL file. This produces a Spring project in which the getAllEntities() method in the EntityNameResource class takes a Criteria argument constructed from the URL GET params.

这与为端点生成的Swagger UI开箱即用，并且此UI发出的查询表明后端期望每个条件采用GET参数键值的形式一对;这与 4.10.2过滤文档一致.

This works out-of-the box with the Swagger UI generated for the endpoint, and the queries issued by this UI demonstrate that the back-end expects each criterion to be in the form of a GET parameter key-value pair; this is consistent with the 4.10.2 Filtering docs.

但是，我想知道是否有一种理想的方法来使用我错过的前端Angular项目中的方法，而不仅仅是自己进行适当的修改以构建一致的URL.

However, I wonderd whether there is an intended approach to using this from a front-end Angular project that I have missed, beyond making appropriate modifications oneself to construct a conforming URL.

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

The front-end services use the static function createRequestOption(req) (exported from app/shared/model/request-util.ts) to populate the GET parameters for paging and sorting. This function also expects that the passed-in req object may have a query attribute; initially, I thought that populating this parameter was the intended way to use the back-end filtration.

但是，createRequestOption(req)的实现当前将req.query的值放入名为query的GET参数中；也就是说，这不会产生后端期望的查询格式，因为每个条件要求每个条件使用单独的GET参数.

However, the implementation of createRequestOption(req) currently places the value of req.query into a GET parameter called query; i.e this does not produce the query format expected by the back-end, which expects a separate GET parameter per criterion.

我使用的解决方案是修改createRequestOption(req)以期望键值对对象数组而不是req.query(我将其称为req.criteria)，并将其添加到URLSearchParams' s数组(必须是数组，而不是映射，因为可能有多个具有相同键的参数，例如name.in=Megatron&name.in=Optimus).

The solution which I have used is to modify createRequestOption(req) to expect an array of key-value pair objects instead of req.query (I've called it req.criteria), and add these to the URLSearchParams's array (it has to be the array, not the map, since there may be multiple parameters with the same key, e.g. name.in=Megatron&name.in=Optimus).

所以我改变了:

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

收件人:

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

...使用组件代码，按照以下内容填充数组:

...with component code populating the array along the lines of the following:

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中使用此方法过滤了测试单实体单片应用程序(当前仅等于查询)

I just created an example of this working in practice with some form fields filtering a test single-entity monolithic app (currently equals queries only) with this approach in GitLab here.

所以，我的问题是:

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

• Have I missed the intended way of doing this with the current JHipster version?
• What is the intended use of req.query in the current implementation of request-utils.ts?
• Is this area expected to change in upcoming versions? For example, might front-end search fields be automatically generated in the way in which ElasticSearch-enabled apps do (but for each entity attribute)?

非常感谢.

推荐答案

我在项目中也做过非常相似的事情，在我的解决方案中，标准的用法如下:

I've done very similar thing in my projects too, in my solution the criteria is used like this:

let criteria = {
   'name.equals' : 'Optimus',
   'power.equals' : '10'
};

当前，我在自动完成"字段上工作，该字段将使用条件，并具有对request-util.ts的必要扩展.这里: https://github.com/jhipster/generator-jhipster/pull/6618

Currently, I work on an 'auto-complete' field, which will use the criteria, and has the necessary extension to the request-util.ts. Here: https://github.com/jhipster/generator-jhipster/pull/6618

是的，我认为，查询"方法的参数有点令人困惑，需要对其进行一些简化.

And yes, I think, that parameters of that 'query' method is bit confusing, it need to be be simplified a bit.

也许，我们可以生成"EntityCriteria.java"的客户端版本，作为"entity-criteria.ts"，但是我不确定.我不断了解新功能和更少的代码.

Maybe, we can generate a client side version of the 'EntityCriteria.java', as 'entity-criteria.ts', but I'm not sure. There is a constant push against new features, and less code, which I could understand.

这篇关于JHipster:使用条件过滤实体-预期的Angular客户端方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！