« Memo to Management: Most IT Workers Looking for New Jobs | Main| Keeping the Domino Blogging World Organized »

Taking up the Show-n-Tell Thursday Challenge

QuickImage Category

So Rocky Oliver and Bruce Elgort have challenged the Domino Blogging community to publish some sort of nifty technical tip every Thursday starting, well, tomorrow. Paul Mooney seems to be the first to meet the challenge, being that tomorrow is already today in Ireland. My plan is to do a writeup of one of two possible bits of code that I've used for years, and I'm willing to be swayed one way or the other should anyone care to state a preference by commenting.

Option #1 would be a way to easily manage form validation messages within the Notes client. The idea is that a single "Validation Subform" can be dropped into any form, and on the querysave it will look for specific field(s) on the form which contain a rollup of all the validation errors that might be generated on that form. The subform will then present a single dialogbox error message with details of ALL the errors found on the document. This is not only more elegant and user-friendly than sequential error dialogs generated from ordinary "Input Validation" formulas, but is also easier to maintain since all the logic is in one computed field. An additional bonus is that you can avoid triggering validation errors when refreshing documents from a view, which can be a tremendous PITA.

Option #2 is a way to track a document's edit history without writing to fields directly on the document, as is typically the case. One of the major problems with the typical approach is that even with "Merge Conflicts" enabled for the form, since every edit must modify the edit history fields, conflicts are inevitable. My alternative approach is to create "stub" documents with just enough information about the parent document to show up in a view and *look* like the parent, as well as the unique docid and the time, date, username, etc. information relating to the edit itself. The stub documents can be collected and sorted many different ways in their own views, so that you end up with a detailed activity history for a database (or collection of them). When you open a document in a history view, a queryopen event redirects the user to the parent document instead of opening the stub document, thus maintaining the illusion. On the parent document itself, the edit history fields that show up are actually computed for display, with lookups pulling in the who and when information from lookup views containing the history stub docs. Another bonus to this approach is that you can call the edit history routine from an agent to create an edit history entry even when documents are edited by some backend batch process.

I'll eventually get around to writing up both, and may even put together a sample database with all the code bits fully baked and post it to the OpenNTF code bin, but let me know if you'd like to see one or the other first.

Finally, I have a request to everyone who downloads code from OpenNTF's code bin: If you find a piece of code useful (or not), please use the rating feature of the site to let everyone know what you thought of it. Developers certainly benefit from the feedback, but it also helps others simply trying to sift through the tremendous number of submissions to find the really excellent ones.


1 - Both sound good but I'd vote for Option 1 first as I'll need exactly that in about a week's time!

Your Host

Kevin Pettitt View Kevin Pettitt's profile on LinkedIn

Tools I Use

Idea Jam

Subscribe to This Blog

 Full Posts  Comments

netvibes Add to Netvibes


Hosted by



This site is in no way affiliated, endorsed, sanctioned, supported, nor blessed by Lotus Software nor IBM Corporation, nor any of my past or future clients (although they are welcome to do so). The opinions, theories, facts, etc. presented here are my own and in no way represent any official pronouncement by me on behalf of any other entity.

© 2005-2019 Kevin Pettitt - all rights reserved as listed below.

Creative Commons License
Unless otherwise labeled by its originating author, the content found on this site is made available under the terms of an Attribution / NonCommercial / ShareAlike