While copy/paste programmers and XPages novices might get something out of this demoapp/blogpost, it's directed towards the people that want to push XPages beyond the constraints of the drag and drop interface in Domino Designer.
I detest the "need" to have a Notes view for every kind view in XPages. Recently, at work, I've been occupied mostly by creating
customizable search/filtering views in XPages.
Until today, I've used a DataTable with a SSJS function as data source (returns JS-objects). The function does an FTSearch on a NotesView, and fetch
precalculated JSON strings from a view column. The DataTable can be designed to use one/all fields from the json-objects. One DataTable column can have one or more values from the JSON object (e.g. dataItem.fieldName + ' ' + dataItem.fieldName2). This has the advantage of only needing a one (unsorted) column view to generate a wide array of reports.
Julian Buss seems to have been working on/pondering solutions for
"on the fly" sortable searches as well. I've implemented what I think he meant in the demoapp as well. I didn't take the time to write caching algorithms for his way,
using NotesViewEntryCollection. I also didn't take the time to implement descending sort. The reason I was so lazy was that I didn't like
my implementation of
his idea.
The last way (default choice in demoapp), and the best way I've found
so far is to do FTSearch on the db. In the demoapp, I search the entire db without restricting to a form/etc. This is because I didn't find the need for restricting the search as there are only one kind of documents in the demoapp. The result from the search is a
NotesDocumentCollection. The datasource is a function that accepts what I call
an array of field definitions.
E.g.
var fieldDefinitons = [{
fieldName: 'someFieldName',
dataType: 'string'
},{
fieldName: 'someFormulaString',
dataType: 'date'
}]
Supported datatypes in the demoapp are string, multi-value string, date, multi-value date, number and multi-value numbers. The field definitions are parsed into a string that can be evaluated against a document (using session.evaluate). Using session.evaluate is the fastest way I know of to get multiple values out of a document. Compared to fetching precalculated JSON strings from a view, there is
no discernible difference in speed when evaluating against documents in the NotesDocumentCollection.
Regarding caching, the JSON object is stored in a
viewScope-variable. When the user navigates to another page, the JSON object should be recycled from what I understand of XPages/JSF. The values are only fetched from the server
when the query string is changed. When the used wants to sort the view, the cached object is resorted. This results in
speedy pagination/sort.
On my local computer, with 5000 items in the result-object, re-sort is done in about 100ms on the server. It probably takes 500-1000ms before the user gets what he ordered. The initial search takes 2-4 seconds (server time).
I could probably write a tiny book on the "technology"/thought/history behind this demoapp. Instead, I'll tease you with an animated gif, and let you download a demoapp (
here be messy code). The demoapp is a biggie. It's a mutilated version of
Jake's FakeNames application. I chose this because I wanted to test against a "big" database. This has 40k NAB Person documents.
Screenshots (animated gif):
>> Demoapp (6 MB zip)Share and enjoy!
