Determine if a Document Belongs in a Given View When Saving
Last week I got an email with a rather unusual request. The sender wanted to know if there was a way to run some code when a document was saved that met the selection criteria of a view in the database. A kind of QueryAddToView event for the view, if you will. I guessed that, although they weren't specific, they chose to ask me as it was a web-based solution they were after. Needless to say it got me thinking.
The only solution I could think of was to call a sub routine at the end of every single WQS Agent associated with all the Forms in the database (or at least those that could potentially appear in the view). The code would have to test the submitted document using the same rules defined in the View's selection criteria. This would be a case of writing a lot of if-based comparisions which mimicked the rules by which documents were selected for the view.
I assume all web forms have a WQS associated with them -- I know all my Forms do nowadays! Even if it's the (wqs Default) agent which just does some standard stuff on ordinary Forms.
Not only could this approach mean a lot of coding, but there's one other major drawback to using it. If any change is made to the selection criteria of the view then the logic in the code you've written to test if the document is going to appear in the view is now faulty.
After a while it dawned on me. There's a much, much easier way to do this. Not only easy but one that requires no change should the view's selection change. We can compare the current document to the view's selection criteria directly using the Evaluate method and the SelectionFormula property of the NotesView object. Here's what I mean:
If Implode( Evaluate( db.GetView("SpecialDocs").SelectionFormula, CurrentDocument ) ) Then Print "This document is special!" End If
So wonderfully simple! If the criteria for what makes a document "special" changes there's no need to change the code!
On first reading the email I'd wondered why on earth they'd want to do that, but, the more I think about it, the more I can see this being of use. I can't think of many real-world scenarios right now but it's something I'll keep at the back of my mind should a need for it arise in the future.
I suppose one simple scenario might be where a support tickets database has a "Top Priority" view in it and certain people want an email each and every time a document lands in it. Just a thought.
Anyway, I put together a quick demo database. At first to test the theory but then I prepped it for guys to play with and download. Enjoy.
Very ingenious indeed !
Didn't know SelectionFormula exists till now.
Thanks Theo.
If nothing else I've at least it's taught you something Sherwin.
I didn't know about it either until Gerald Mengisen told me about when I was looking for a date-based views solution - if you haven't already it's a must read: {Link}
How does this work? I just can't wrap my head around it as it doesn't make sense to me.
I don't know what you mean Richard. What doesn't make sense? What don't you get? It's fairly simple.
The Evaluate expression doesn't make sense to me.
First part of Evaluate, you're getting a view's selection formula.
Second part of Evaluate, you have the doc.
Then what happens? Are you saying that the Evaluate expression will return true or false if the doc meets the selection formula criteria?
"Are you saying that the Evaluate expression will return true or false if the doc meets the selection formula criteria?"
Yes. And so it tells you whether the document does/will appear in the given view.
Interesting technique, Jake. I knew about SelectionFormula, but I had no idea using it in Evaluate with a NotesDocument would work like that.
Richard, that's it exactly. The help isn't really clear, but Evaluate is running the SelectionFormula of the view against the document you pass to it. If the selection formula would include the document you give it Evaluate returns True -- as an array, which is why Jake uses Implode around it.