テーブル | AppMaster

最初のレコードがデータベースに現れました!しかし、それが見えないので、修正する必要があります。これを行うには Tableコンポーネント(必要なデータを表示するテーブル)を追加します。追加するとすぐに、どのようなデータを入れるかを決定し、モデルとエンドポイントを選択するように求められます。

テーブルの設定

作成されたテーブルは、すぐにお客様のご要望に沿った形で発行する必要があります。例えば、1ページのレコード数を制限したり（テーブルは非常に長く、複数ページになることがある）、興味のないフィールドを削除したり、関連するテーブルから出力するために必要なフィールドを設定したりすることができる。

同時に、単にコンポーネントを追加しただけでは、まだ完全な作業準備が整ったとは言えないことを忘れないようにします。適切なビジネス・プロセスを作成する必要がある。テーブルについては、多くのものが自動的に作成されますが、トレーニングの一環として、材料をよりよく吸収するために、すべてをゼロから作成します。

テーブルトリガー

テーブルには、最も関心のある3つのトリガーがあります。 onDataUpdate, onShowと onFilter.で始めましょう。 onShowから始めて、テーブルが画面に表示されたときに起こるべきことを定義します。これには3つのブロックが必要です。

1) Table Update Properties.テーブルの所望のプロパティを設定します。例えば、ここでは1ページに表示するレコードの数を制限したり(パラメータを Records per page = 10を設定)、また、ページがデータ読み込みモードであることを表示する(Loading = true)

2) Server request GET /country/.データを表示するためには、データをどこかに取り込む必要があります。そして、そのためには、対応するエンドポイントに対して、データベースへのリクエストを行う。同時に、このエンドポイントの入力パラメータの数にも注意を払う。これらは、クエリに柔軟性を与え、本当に必要なデータのみを取得します。
この例では _limit = 10なぜなら、1ページあたりのエントリ数は10であり、それ以上ロードする意味がないからです。さらに、正しい出力順序を作り、すべてを名前順(_sort_by = name)でソートし、さらにソート順を設定します。という _sort_orderパラメータは値をとることができます。 ASC(Ascending, 直接ソートの場合、小さい値から大きい値へ) または DESC(Descending, 逆順) を取ることができます。アルファベット順の直接ソートで問題ないので _sort_order = ASC.

この _withパラメータは特別な注意を払う必要があります。このパラメータを指定せずにクエリを実行すると、国に関するデータしか取得できません。しかし、国のモデルは都市と関連しており、このデータは要求されたテーブルに属していませんが、我々はまだそれらを見たいと思っています。これを行うには _with = citysをセットして、この国にどんな都市があるかというデータをすぐに取得します。

3) Table Update Data.データは受け取ったが、画面に表示するためにテーブルに転送する必要がある。そのために、前のブロックで受け取ったすべての情報(data)と、レコードの総数(count - Total Records) を渡し、テーブルに何ページあるべきかを理解します。

次のトリガーは onDataUpdate.テーブルのデータは、様々なビジネスプロセスの結果、更新されることがあります。そして、このようなことが起こった場合、何が起こるべきかを一度指定し、各ビジネスプロセスで同じブロックを配置しないことが最善である。この場合、再び Table Update Propertiesブロックを使用するのが正しいのですが、今回は先に設定したロード・モード(Loading = false) を削除し、テーブルが動作可能な状態にあることを示します。

最後に必要なトリガーは onFilter.これは、テーブルの他のページへの遷移の瞬間に起こるべきことを定義しています。これを行うために、これは _offsetパラメータがあり、ページ番号に従って、データをロードするときに必要なオフセットが示されます。

たとえば、各ページに 10 個のエントリがある場合、3 ページ目には 21 から 30 までのエントリが必要となる。このデータは _offsetブロックに渡すことができます。 Server request GET /country/ブロックに渡すことができます。そうでなければ、ビジネスプロセスは完全に TableOnShowトリガーと完全に一致してしまう。このような状況では、2つの異なるトリガーが同じビジネスプロセスを起動させることは合理的でしょう。

しかし、今回のケースでは、重要な違いは _offsetパラメータにあります。もし、以下のスクリーンショットのように全てをそのままにしておくと、プロセスはトリガーに従って開始されます。 onShowトリガーに従って開始されますが Server request GET /country/ブロックの中で停止します。 _offsetを取得できないため、ブロック内で停止してしまいます（別のトリガーから渡されます）。

この状況は、変数を使うことで解決できます。具体的な例を見てみましょう。値を保存するために、Integer 型の変数が必要です。 _offset値を保存するために、型の変数が必要です。そのため、この変数を宣言するために1つの Integerこの変数を宣言するために1つのブロックを使いますが、値を書き込むために2つの異なる Set Variableブロックがあり、それぞれが異なるトリガーに関連付けられます。

それぞれ異なるトリガーに対応しています。 Table onShowトリガーによると、オフセットは必要なく、表のデータは最初から表示され _offset = 0を設定します。 Value = 0を Set Variableブロックに設定します．

トリガーが起動すると Table onFilterトリガが起動したとき、我々はすでにその値を受け取り _offsetの値を受け取り、それを使いたいので、トリガーの値を _offsetをトリガーの値として Valueに渡します。 Set Variableブロックに渡す。

次のステップでは、トリガーのビジネスプロセスは互いに異なるものではないので、2つのビジネスプロセスを1つにまとめ、それぞれに整数型変数の値として _offsetパラメータを指定します。