1800 のフィールドと 7 つのタブを持つクラシックな Lotus Notes フォームがあります。
- フォームを 7 つの異なるフォームに分割して xpages または
- フォームを xpages に直接バインドすると、パフォーマンスに影響がありますか?
ありがとう
1800 のフィールドと 7 つのタブを持つクラシックな Lotus Notes フォームがあります。
ありがとう
これは、「RDBMS で試してみる」タイプの状況です。フォームを分割しても役に立ちません。XPages は、バインディングの数が多い場合 (多くのフォームでまだ比率が 200 を超えている場合)、使用されるデータ ソースの数をあまり気にしません。フォームにバインドするのではなく、ドキュメントにバインドします。フォームは「設計時の便宜」にすぎません。
いくつかのワイルドな推測を行うと、多くのフィールドが複数値フィールドではなく繰り返しフィールド ( LineItem_1 LineItem_2 LineItem_3 など) であると推測されます。
先に進むには、基本的な選択を行う必要があります。
すべてのビュー、レポート、インポート/エクスポート ルーチンなどはそれらに依存しているため、データ形式は固定されていますか。データモデルをリファクタリングできますか (あなたの質問に基づいて、私は前者を推測します)。
修正された場合、フィールドの繰り返しセットと実際に必要なエントリ数を表示する繰り返しコントロールのデータのコレクションを提供するマネージド Bean にドキュメントをカプセル化することを検討します (古典的な方法は、異なる非表示にすることですフィールドをホストするテーブルのすべてのセル)。このようにして、世話をするバインディングがはるかに少なくなります。
動的テーブルを作成するための非常に基本的なアイデアは、IBM XPages チュートリアルの演習 23にあります。
免責事項:ティム・クラークと私が書いたものです。
また、特定のユーザーがその瞬間に必要とするドキュメントの部分のみを使用することを検討することもできます。
このような状況では、私の懸念として、7つのタブと1800のフィールドを持つフォームがあります。しかし、それは複雑すぎます。ただし、フォームを7つに分割すると、各フォームには260のフィールドがあります。これで、コードも複雑になります。
しかし、私の提案は、xpagesのバインディングデータを動的に変更できることです。フォームの再設計が非常に複雑だと感じる場合は、上記の考え方に従ってください。それ以外の場合は、デザインを変更して、xpagesで見栄えを良くしてください。