1

文書内の Readers フィールドを利用する既存のビューに対して、代替 XPage で Dojo DataGrid コントロールを (本番環境に影響を与えないように) 試行します。REST サービス (xe:viewItemFileService) を実装し、Dojo DataGrid に正常に接続しました (8.5.3 UP1 コントロールから)。

ユーザーの可視性には 2 つのシナリオがあります (NAB グループ定義によって割り当てられた [リーダー] フィールドのロールを介して):

  1. すべてのドキュメントが表示されます (ユーザー A)。ユーザー A はすべてのドキュメントを表示できます。このドキュメントではすべてが問題なく機能します。
  2. ユーザー B はいくつかのドキュメントを表示できます。ViewPanel コントロールは正常に動作しますが、いったん Dojo DataGrid に入ると、ユーザー B が表示する必要があるドキュメントの値しか持たず、残りの X (正しく表示されているドキュメント数と合計ドキュメント数の差) の行には "..." (non-値)。

pathInfo を介して REST サービスの出力を調べると、ユーザー B の正しいドキュメントのみが生成されます。私はこれを良い兆候と考えており、Dojo DataGrid が間違った動作をしていると考えさせられます。

実際の質問:
不要な行の生成を抑制するにはどうすればよいですか?

私はMarky Roden のアプローチを実装しようとしましたが、行数を生成するために DataGrid が見ているものを制御する方法の操作に迷いました (私が xe:djxDataGrid コントロールを使用しているときに、彼はプログラムによるストア定義について話しています)。rowsPerPage の属性は正しくないようです。また、探しているものにとって意味のある xe:restService の属性が見つかりません。

誰でもこれを行う方法を知っていますか? この仕事を手に入れたいです。Brad Balassaitisによるシリーズと、XPages が私たちのためにできることを愛しています。

セットアップ:サーバー ID として署名された
Domino Server 8.5.3 UP1
NSF

4

1 に答える 1

2

グリッドは、ユーザー B が表示できるドキュメントの数だけでなく、実際の数を示す ?readViewEntriews から行数のヒントを取得します。とにかく、アクセス速度を考慮せずにリーダー保護されたビューをただぶらぶらするだけでは、パフォーマンスに大きな影響があります。読者/作成者フィールドを組み合わせてビューを分類し、そのカテゴリに制限すると、パフォーマンスと空の行の両方がなくなります。複数の可能性のあるヒット (ユーザー名、ロール、グループ メンバーシップ) がある場合は、viewNavigator を使用して何らかの SSJS を使用してデータを返すレスト サービスを使用することをお勧めします。

于 2013-05-03T23:21:15.567 に答える