This one's going to be a real concept-based article, so kids and parents with weak stomachs may want to stop reading at this point (please read that if you're looking for a copy/paste code snippet, please keep moving along...!)

Ok, VSFs (View Selection Formulas) - a very basic function, but recently I've been working on enhancing view usage via a combination of document-level rules and some Lotus Notes Kung-Foo.

A quick example:

I need a view for all open tickets in my Helpdesk system (guess what I've been working on lately...):

SELECT ( (form = "ticket") & (status = "Open") )

VERY basic stuff here... but what if you needed a more controllable view, a more finite list, but didn't want to have to modify your VSFs everytime someone in Customer Service said "hey! I got an idea..."?

Let's say I want to control just where a document is going, at any point within the documents life, at any point within my application. The solution that I am suggesting here is a three-step process:

1. Add a field to your form.
2. Modify your VSFs.
3. Add "rules" via the workflow and function of your application to populate said field.

First, we'll add a field to your forms: vInclude

We will use this Computed to itself multi-value text field in the next two steps, but the basics are to create this hidden field used soley (for this example) to populate what views I wish to display this document in... but more on that later.

We'll now modify our VSFs by settings this very blanket yet dynamic and functional formula:

SELECT vInclude="" | @IsMember(@Subset(@ViewTitle;-1);vInclude)

This tells the view to include all documents that either don't have the vInclude populated, or that have it populated with the alias of the current view.

For example of this in action:

View Title: Open Tickets|opentickets

If you set the document's vInclude field to "opentickets" or "opentickets":"openbydept", this document will be set to display in the Open Tickets view.

For the addition of "rules" via workflow and function for your application, I'm talking about manipulating your application to populate the vInclude field. This makes sense for, say, a Helpdesk application.

The logic: if it's an open ticket and a master ticket with with child/dependant tickets, set the vInclude field to "opentickets":"openbydept":"openmastertickets".

While this approach may not be suited for all of your applications, I've found already that it lends true Rapid Application Development for the creation of many views - it's pretty much just copy/paste, knowing that the View Selection Formula will always be accurate!