web-dev-qa-db-ja.com

JHipster：基準によるエンティティのフィルタリング-意図したAngularクライアント側のアプローチ

私は最近 JHipster を使い始めました-この素晴らしいプロジェクトのメンテナに感謝します！

JHipsterの現在のバージョン（執筆時点では4.10.2）では、エンティティサブエンティティを使用して、またはプロジェクトのJDLファイルに_filter EntityName_と_service EntityName with serviceClass_を含めることで、エンティティでフィルタリングを有効にできます。これにより、EntityNameResourceクラスのgetAllEntities()メソッドがURL Criteria paramsから構築されたGET引数を受け取るSpringプロジェクトが生成されます。

これは、エンドポイント用に生成されたSwagger UIですぐに機能し、このUIによって発行されたクエリは、バックエンドが各基準がGETパラメーターKey-Valueの形式であることを期待していることを示していますペア;これは 4.10.2 Filtering docs と一致しています。

しかし、私はこれをフロントエンドから使用する意図されたアプローチがあるかどうか疑問に思っていますAngular私が見逃したプロジェクト、適切な変更を加えて適合URLを構築することを超えて。

フロントエンドサービスは、静的関数createRequestOption(req)（_app/shared/model/request-util.ts_からエクスポート）を使用して、ページングと並べ替えのGETパラメーターを設定します。この関数は、渡されたreqオブジェクトがquery属性を持つことも想定しています。最初は、このパラメーターの設定がバックエンドフィルターを使用するための意図された方法であると思いました。

ただし、createRequestOption(req)の実装では、現在_req.query_の値をGETというqueryパラメータに配置しています。つまり、これは、基準ごとに個別のGETパラメータを想定しているバックエンドが想定するクエリ形式を生成しません。

私が使用した解決策は、_req.query_ではなく、キーと値のペアオブジェクトの配列を期待するようにcreateRequestOption(req)を変更し、これらを_req.criteria_と呼んでいます。 URLSearchParamsの配列（同じキーを持つ複数のパラメーターがある場合があるため、これはマップではなく配列である必要があります。例：_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);
    });
}
_

...次の行に沿って配列を生成するコンポーネントコードを使用します。

_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対応のアプリが行う方法で（ただし、エンティティ属性ごとに）フロントエンド検索フィールドが自動的に生成されますか？

どうもありがとう。

angularjhipster
7
ImperfectClone

私のプロジェクトでも非常によく似たことが行われています。私のソリューションでは、基準は次のように使用されています。

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

現在、私は「オートコンプリート」フィールドに取り組んでいます。このフィールドは基準を使用し、request-util.tsに必要な拡張機能を備えています。ここ： https://github.com/jhipster/generator-jhipster/pull/6618

はい、その「クエリ」メソッドのパラメーターは少しわかりにくいと思います。少し単純化する必要があります。

おそらく、「EntityCriteria.Java」のクライアント側バージョンを「entity-criteria.ts」として生成できますが、よくわかりません。新機能に対する不断のプッシュがあり、理解できるコードは少ないです。

6
Renszarv