Requires Free Membership to View
Register today to access targeted resources from our editorial writers and independent industry experts focused on Lotus Domino, Notes, Workplace and other related technologies.
I'm assuming that you have a view that shows the documents, that each document contains one image and that you've set the view to show 9 documents per page. You're using JavaScript and the document.write statement to format the HTML to display the images in a 3x3 table. You probably don't want to use the default view action buttons for next and previous, because they will overlap the values -- they would advance or go back 8 images at a time, not 9. So you program your own navigation using JavaScript to calculate a new URL based on the Count= in the current URL.
You can also use JavaScript to calculate the HTML for the number of pages and the links that would appear there. The problem is how to get the raw data that this requires -- the total number of images.
If you were doing a Search Template form, you could use the TotalHits computed field, which is automatically filled in with the number of documents that matched the search. In a View Template, however, you have to calculate this yourself. You can do this either with a computed field (@Elements(@DbColumn(...))) or else using a WebQueryOpen agent on the $$ViewTemplate form. The latter may be slower for smaller document sets, but it's faster for large ones because you can use NotesViewNavigator.Count as opposed to reading all the data in the view; it also is more scalable, since @DbColumn will fail to return all the view data if it exceeds 64 KB. The WebQuerySave can write its findings into a field in the document, which you can use as part of the pass-thru HTML. Or, if the form is set to render all fields as HTML, you can hide the field and refer to its value directly in your JavaScript code.
If performance is a concern, you could speed things up by storing the document count in a field of a profile document; a server agent would periodically update the profile document, so that in your view template form you could just refer to its value using @GetProfileField, which is fast. You may have some caching issues, however -- I wouldn't know without trying. If the Domino form's macro interpreter doesn't use the same profile data cache as the agent manager on the same server. An environment variable may be more reliable.
This was first published in October 2003