Drill-down Views

Reader fields

Related links:
Filtering Domino Web Data Sample download

Adding a friendly ad-hoc query tool to your Domino applications

Lotus Developer Central

Get the PDF:
(677Kb)

When you develop Domino applications, one of the most common requests from Web users is: "Can I get a view that shows just my department's information?" This is easy if there are three departments, but if there are 37, and three different specialties within each, you would be maintaining far too many views if you gave each department its own set of views. However, you can still filter data for users by doing such things as: showing them only documents authored by or assigned to them, or by allowing the users to run ad-hoc queries against the database.

This article explores several ways to filter data for your Web users to give them only the data they want to see, or to give them only the data you want them to be able to see. There are three main techniques for presenting such restricted sets of data. We will discuss each briefly here, along with its advantages and disadvantages. You can then learn about each technique in more detail. All the examples you see here are working examples you can try by downloading the sample database in the Sandbox.

The article assumes you have experience in developing Domino applications for the Web. It presents several Notes and Domino design techniques that you would most likely need training and/or hands-on experience to follow.


Techniques for filtering data for Web users
We'll discuss the following three techniques for filtering data for Domino Web users:

1. Ad-hoc Queries. With this technique, the user fills out a simple form to define the criteria by which she wishes to filter the data. The form generates a field-specific full-text query, which is then passed back to Domino. Domino in turn returns the results to the user. This technique is an excellent way of letting the user pick a very detailed set of criteria by which to filter the data. And the full-text search engine runs these queries very quickly. Running the query and returning the results to the user involve very little code, but the formulas to generate the full-text query are somewhat complex for those new to the Notes formula language and its list processing capabilities.
2. Drill-down Views. This technique combines the use of the @DbLookup command with hidden views, so you can present users with an initial set of data and then let them "drill down" to lower level data. For example, if you want users to see only the projects for which they are defined as Project Manager, you define a hidden view that shows all projects grouped by manager, and use that view along with the user names to look up projects. You display these results in a computed-for-display field on a form, adding the necessary HTML to make the returned hits appear as "hot" links.
   
   The disadvantage is that this technique does not display any real Notes views to the user, so you must generate your own HTML links. It is not the best approach for a complex, user-chosen set of filtering criteria, since an @DbLookup can only filter one key at a time, and by pre-defined criteria (in pre-defined hidden views).
3. Readers fields. Readers fields are fields that restrict the ability to read a given document to a specific set of users. This is another way of making sure your users only see the transactions pertaining to them. In the projects and action items example, you could create a shared view called "My Action Items." If you defined a Reader restrictions field on your action item form that allows only the assignor, the assignee, and administrators to read the document, then users can open the My Action Items view and see only their own items.



Conclusion
We have explored three techniques for filtering data for Web users. Each technique has its place, and the first two can even be combined: we could let users do ad-hoc queries from one link on the Action Items home page, and from another link, let them drill down to view projects and action items pertaining to them. The Readers technique is different from the other two in that it is applying security to restrict what the user sees, and so it is appropriate where this security is necessary.

Copyright 1998 Iris Associates, Inc. All rights reserved.