For christmas I want a new @Function. It has to be called @ViewCount("ViewName") and it has to be really really super-dooper fast. Faster than Tommy's next door. He says his mummy is getting him SQL this year and that it can do it in one zillionth of a second with 3 million trillion documents. I want mine to be infinity+1 faster than that. Please. I will be a good boy all year. I promise to stop saying nasty things about Domino.
Jake (aged 29)
The more I think about the code Domino generates the more I am convinced we need to take charge. This is especially true with websites. It's no longer the case that you can impress The Boss merely by showing them a Notes database in a browser that they can edit and save. Remember when you could press Submit and amaze people with how the page updated in the browser, there and then!? Nowadays they want it all. They've used the web long enough to know exactly what you can and can't do. Now, if I had a pound for every time I had said "You can't really do that with Domino"...
If you let Domino do the coding for you there will be numerous problems. For example, normal domino views don't navigate all that well. I've created a sample database with 23 documents in it, named numerically. Look at the normal Domino view that used ViewNextPage style hotspots. Notice there's a previous link even though we're on the first page. Press it and the page simply reloads. Press the Next button and notice the view starts with the last document from the previous page. Keep pressing Next until you get to the last page. Press Next again and it takes you to a page with just the last document in it. Keep pressing Next and this page keeps re-loading. Now explain all this the Boss/Customer and why you can't change it.
Well, I've got someway towards a solution. All we need to do is find the count of documents in the view and set a field on the view's $$ViewTemplate to this value. This is done in a WQO agent. The rest can be done with @Functions. Here's the first bit of code I tried:
Set nav = view.CreateViewNav()
Call doc.ReplaceItemValue( "Total", nav.Count)
I also added some code to the agent that computed the time before and after this code, worked out the difference and sent this to the page as well.
Opening a view with 5,000 docs took 2 seconds, with 10,000 docs it took 7s and with 15,000 it took 9s. Not good! So I swapped the NotesViewNavigator for a NotesViewEntryCollection and the 15,000 documents were counted in 3s. Better, but still not great. Then I switched to a NotesDocumentCollection and used the following code:
Call doc.ReplaceItemValue( "Total", col.Count)
This took 0s with 15,000 documents. Better. Obviously we dont want all document though. So I tried the NotesDatabase.Search() method, which also returns a NotesDocumentCollection, of which count is a property. I passed the search method the same formula as the selection criteria for the view in question and 15,000 docs took 0s. Increasing to 25,000 took 1s and 91,000 took 3s.
So, we can work out the number of documents in a view and create our own navigation. I've done so in this "super" view, which shows the same documents. Notice how next page doesn't include any documents from the previous page!
If you open the actual documents you'll notice that they have next/previous navigation at the document level. Not only that but they include the title of the relevant entry. This is based on the code I posted on Wednesday. The good news is that document-specific navigation of a NotesViewNavigator seems to be unaffected by the number of documents in the view.
Thanks for reading. Article to follow...