Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

The requirement:

Create a "my documents" view for the user.

The obstacle:

@Username can't be used in a shared view selection formula. That's because for a view index calculated by the server, @Username is the name of the server.

Common approaches:

  • Create a "Desktop private on first use" view; now if you use @Username, it's the user's own name. Drawbacks are that it tends to be slow, especially the first time it's used, takes up space on the user's disk, and updating the design of the view is a challenge since there's nothing to force an update of users' private copies.
  • Use NotesView.SelectionFormula to update the view's selection formula every time someone opens it. This is a really dumb idea for several reasons: it's slow, it requires users have Designer access, changes to design elements at runtime often don't work well since the client caches design elements, and users would interfere with each other by using the view at the same time. Don't even think about doing this.
  • Create a single view containing all users' documents, categorized by username. Then use the view in a way that has it display only a single category. There are two ways to do this in the Notes client:
    • Embed the view on a form or page design element, and use a Single Category formula such as @Username or @V3UserName. Very easy, but there are some things that don't work so well in an embedded view, including full-text search, sort by clicking column headers, and view links and bookmarks.
    • Open the view as you normally would, but use Postopen view event code to limit the display to the user's category by means of a call to @SetViewInfo.
It's this last technique I describe below.

How to Do It:

The formula for the view Postopen event is:

@SetViewInfo([SetViewFilter]; @UserName; "columnName"; 1; 1)

where you would substitute the actual column name of the categorized column, in place of columnName.

The formula for the view Queryclose must clear the limitation, or it will affect other views in your application. Here's the formula for that:

@Command([OpenView]; @Subset(@ViewTitle; -1));
@SetViewInfo([SetViewFilter]; ""; "columnName"; 1)

where you need to substitute for frameName, the name of the frame containing your view, and for columnName, the name of the categorized column. This assumes the view is displayed in a frame of a frameset, as is typical for a Notes client application. If it is not the case for your application, you can leave off the first line.

The purpose of opening the view that's already open, as we do in line 3 of the Queryopen formula, is to cause focus to enter that frame, in case it is elsewhere (as it probably will be if you clicked on a link in another frame to switch to a different view). If you don't do this, @SetViewInfo may fail because it's a view command being used in a frame that doesn't contain a view.


  • The functionality 'Click on column header to sort' is not available. You can, however, use this same technique in multiple views that use different sorting after the category column, and click on column header to switch views.
  • If you do a full-text search, the status bar will display the number of hits for the whole view, not just your category (but only the matches from your category will display).

Andre Guirard | 20 July 2010 03:56:55 PM ET | Man-Cave, Plymouth, MN, USA | Comments (11)


1) Hmmm
Erik Brooks | 7/20/2010 10:47:03 PM

At first I was reading this, wondering "Why is Andre talking about legacy N/D dev with a technique that people have already been using for ages?"

But I see it now - focus issues. Good to know. Thanks!

2) Question
tom oneil | 7/21/2010 8:01:03 AM

Does this solution scale well? We've had legacy databases run great with private views until the apps became widely popular and had 100k+ documents.

3) @Erik...
Andre Guirard | 7/21/2010 8:30:30 AM

and also so I have a link for people when they seem to need to know this in the forums.

4) does work on one categorie but not other
benoit maillet | 7/21/2010 12:39:55 PM


i've juste tested this, and on a view, i got three categories:

a date, a common name and an affair number.

if i filter on the date, the view is well filtered.

if i filter on the common name, no category is found.

i've put the common name category on the first column to test and result is the same, no category found.

did you know where i can look to resolve this issue.

here is the filter:


even if i put a name (ie "john doe") that is on the view, no category is returned.

thanks for sharing all this.

5) Scalability and scope of solution
Andre Guirard | 7/21/2010 6:13:11 PM

@benoit: Regrettably, @SetViewInfo only works on the first categorized column of the view. I know, then why do you have to specify the column name? Don't ask me, I didn't do it. But if you understand the architecture of views indexing, the reasons for it are obvious. You couldn't get reasonable performance on this for anything except the first sort key of the view.

@tom: The whole point of this is to allow it to scale up. The speed is comparable to the same view used without single-category. Since all users share the same view index, it's not as much work for the server's indexing process, and the index tends to be pretty much up to date when you use it, because of someone else's recent use or the auto-indexing, so it doesn't take long to update.

6) @SetViewInfo
Doug Finner | 7/21/2010 7:24:34 PM

We have an app the holds assembly process documents; each 'Process Number' contains <n> docs, and the view is categorized on the Process Number. For our larger build programs, we can have a hundred or more proc numbers. For the user who only builds one process, @SetView info used in conjunction with a profile doc allows the user to see just the one process they use. For users who build multiple items (ie more than one process), their profile doc contains the list of process numbers they use. The view has a button that displays the user's list, let's them pick one, and then that process is displayed. Time to build a new process? Pick the next number and see just that.

I love this function!

7) There are some problems
Jens Winkelmann | 7/22/2010 12:37:46 PM

A) When the user calls 'View\Expand/Collapse\Collapse All' from the menu, sometimes all documents disappear from the view.

That is because the displayed category is now collapsed and so no documents are visible.

Users with no technical background doesn't understand this.

B) The functionality 'Click on column header to sort' is not available.

That's a pity.

C) Fulltext search in the view works, which does not for embedded single category views.

But in the status bar you see the number of all hits in the whole view, but the user expect the number of hits in the current category.

D) Do view links work? Maybe with your solution they work.

8) works on any column
Ravi | 7/22/2010 12:39:06 PM

@5:I have a calendar view and I filter it based on department, and the department column is the last column and it is not sorted or categorized. This view shows the vacations for the persons department. The below code is in postopen event.

@Command( [CalendarFormat] ; "20");

Dept:=@DbLookup("":NoCache; @ServerName :"apps/ehr.nsf"; "($LotusName)";@Name([Abbreviate]; @UserName); "emp_SubDepartment";[FailSilent]);

@SetViewInfo([SetViewFilter]; @Trim(@Right(Dept;"-")); "$17"; FALSE; 1)

9) Limitations and calendar view differences
Andre Guirard | 7/22/2010 1:31:22 PM

@Ravi, yes, calendar views work differently. Because there's a limited number of documents that are candidates for display on one calendar sheet anyway, it's reasonably efficient to filter them. For a categorized view, however, if you try to limit the display based on a column that's not the main sort column, your candidate documents are scattered all across the view index with no efficient way of finding them; they're not all grouped together by date like in a calendar view.

@Jens, good points mostly, and I think I'll change the blog entry to mention them (so for people who read this later: Jens is not a fool who doesn't know how to read -- the entry changed after he read it). I've been trying expand/collapse all in 8.5.2 and I don't see the problem you mention, so that might have been fixed. View links do work; why not? The Postopen event should still run.

10) Expand Collapse
Ravi | 7/22/2010 1:51:36 PM

@Jens:View expand collapse should work fine since 8.5(I noticed)in embedded view and this type of filtered views.

Another point not related,is that when we "copy as table" from a embedded view/filtered view with multiple categories, there are duplicate rows in the table.

11) Performance Comparison
Gregg Bendtsen | 12/16/2010 12:44:51 PM

Hi, Andre:

Of the techniques you outline, I have used the second-to-last that is described under Common Approaches, starting with “Embed the view on a form or page design element, and use a Single Category…” Do you know if the @SetViewInfo technique you describe is faster than the "Embed in form or page" method?

Also, I have tried using @SetViewInfo in a calendar view before, as Ravi describes, and didn't have good results. I gave up on that one, but might revisit it now that I have read your post.

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact