Search code examples
xpagesdojox.grid.datagridxpages-extlib

Dojo DataGrid (8.5.3 UP1) Returning Blank Rows - based on Readers field


Trying out a Dojo DataGrid control on an alternate XPage (so as not to impact production) for an existing View, which utilizes Readers fields in the documents. I've got the REST service implemented (xe:viewItemFileService) and connected to the Dojo DataGrid just fine (from 8.5.3 UP1 controls).

I have two scenarios of user visibility (via Roles in the Readers field, assigned by NAB Group definition):

  1. All documents visible (user A). User A can see all documents, everything works perfectly fine for this one.
  2. User B can see some documents. ViewPanel control works fine, but once it's in the Dojo DataGrid, it only has values for the documents User B should see, the remaining X (difference between correctly visible and total document count) rows are populated with "..." (non-values).

Inspecting the REST service's output via the pathInfo yields only the correct documents for User B; which I take as a good sign and makes me think the Dojo DataGrid is what's misbehaving.

Actual Question:
How can I suppress the generation of the unnecessary rows?

I've tried to implement Marky Roden's approach, but got lost on the manipulation of how I can control what the DataGrid is looking at to generate row count (he's talking programmatic store definitions when I'm using the xe:djxDataGrid control). The attribute of rowsPerPage doesn't seem right, and I can't find one for the xe:restService that would make sense to me for what I'm looking for.

Anyone know how to do this? Would love to get this work. Been loving the series by Brad Balassaitis and what XPages can do for us.

Setup:
Domino Server 8.5.3 UP1
NSF signed as Server ID


Solution

  • The grid gets the hint for the number of rows from ?readViewEntriews which tells the actual number, not just the number of documents user B can see. Anyway just romping through reader protected views without designing for access speed has huge performance ramifications. If you can categorize the view by the combined reader/author fields and limit to that category both performance and empty rows will go away. If you have multiple possible hits (username, role, group membership), you might want to use a rest service that returns data using some SSJS using a viewNavigator