In this episode, we work on more Views for our Event Admins, including an "Event Calendar" Calendar-type View, and use both Shared Columns and a "Color" User Profile to complete a simple yet powerful user interface for our Lotus Notes application.

View Full-Size Video

Author's Note: Let me know if you like these screencasts: the non-formal approach that I'm taking as well as the content itself that I'm convering. For the high-resolution, full-screen videos, I'm first tried Vimeo.com and now ScreenCast.com - both under the "free" license. An annual premium account would run me $60USD/$100USD respectively, so if you like what you see - or have any problems with the content or the service - please let me know!

- Update -

Public Build: Event Calendar - Screencast Episode 2 from Chris Toohey on Vimeo.

I really like the Vimeo service - so I'm providing a smaller-resolution screencast should you feel the same way. While you won't see the specific lines of code, I think it's a better usage experience.

The majority of the Lotus Notes Applications I've written lately - from customer applications to the freeware/tip jar-ware that I've been publishing to this site - all feature a Preferences NotesDocument, which contains... well, preferences for the given application. The Preferences Document is a simple NotesDocument containing Keywords and other data items that help the given Notes Application do whatever it's supposed to do.

Now, before we even hear from anyone asking "Why aren't you using Profile Documents?" - issues like HTTP Caching and their tendency to corrupt keep them off my radar. And, in the spirit of being truthful here: I just prefer to handle a NotesDocument as a NotesDocument, not some voodoo mystery back-end thing that's really just a special type of - you guessed it - NotesDocument.

There are, however, some issues with the Preferences NotesDocument approach. The biggest being it's dependancy on a Domino Views for NotesDocument lookups. For example, I've added a Domino View named (bykey)|bykey into pretty much all of the freeware/tip jar-ware applications, but it's there for the sole purpose of providing me with a lookup-point to get a handle on the Preferences Document. So... what's wrong with that?!

How many of you have a 2GB+ Domino Application lying around? Okay... do this for me. Create a new view containing any number of columns that you want, that shows all NotesDocuments in the database... and tell me how long that takes to open.

Now, run this simple script against your 2GB+ Domino Application:

Function getDocs() As NotesDocumentCollection
 
 Dim s As New NotesSession
 Dim db As NotesDatabase
 Dim col As NotesDocumentCollection
 
 Set db = s.GetDatabase("", "db.nsf")
 Set col = db.AllDocuments
 
 Msgbox "Got " & Cstr(col.Count) & " NotesDocuments!"
 
End Function

Obviously change your db declaration to get a handle on your 2GB+ Domino Application... but you get the idea here. What slows down your Domino Applications are NOT the number of or size of your NotesDocuments... it's their rendering in Domino Views. Sure - they cache... but ViewIndex caching makes the Domino Application even larger than it really needs to be, and what happens when something happens to the View or the ViewIndex itself? Yeah, prepare to stare at your Lotus Notes Client for a while...

I don't want to add to that for a Preferences Document. How can I justify that bloat to just allow someone to assign keywords and other Domino Application... stuff to make it work. Yeah, I can't do that in good conscience. And I have been doing just that...

So, from now on, my freeware/tip jar-ware Domino Applications are going to use the following approach, recently popularized by Andrew and Nathan. Specifically, I'm going to logically-define the "Preferences" NotesDocument UniversalID!

Doing this is pretty simple actually... I just need to define a schema and stick with it. So, for example, let's say that this will be for a global Preferences Document. We'll create our @Password HASH logic to create a UNID for our Preferences Document:

@ReplaceSubString(@Text(@Password("preferences")); "(":")";"")

So... my real problem with this approach is that I don't like having to bail out of whatever language I'm running at the given moment to get a handle on the Preferences Document UNID. I want to keep the Evaluates to a minimum here, so I'll look to the Lotus Notes Client cookie-like behavior of the Environment Variables to provide me with access-from-anything cache of the UNID for my Preferences Document.

To do this, I've simply added the following to the Initialize Event in my Applications Database Script:

Sub Initialize
 
 Dim s As New NotesSession
 Dim hash As String
 
 hash = s.GetEnvironmentString(|HASH_preferences|)
 If Len(hash) = 0 Then
  hash = Join(Evaluate(|@ReplaceSubString(@Text(@Password("preferences")); "(":")";"")|), "")
  Call s.SetEnvironmentVar(|HASH_preferences|, hash)
 End If
 
End Sub

Pretty basic stuff here, as this creates the following line in the Notes.ini:

$HASH_preferences=A68506D12B73EC4E4A77FB934144FD97

So, since we've taken the steps to set the UNID of our Preferences Document to be the evaluated @Password hash of "preferences", we can now use the Preference Document via View Index-free lookups in (for example) just one of the following ways:

1. @GetDocField(@Environment("HASH_preferences"); "Categories");
2. Set doc = db.GetDocumentByUNID(s.GetEnvironmentString("HASH_preferences"))

Now, while I will place this into the freeware/tip jar-ware Domino Applications as just Preference Document lookups... keep in mind that you can easily expand this to evaluate more user-specific lookups by adding such considerations into your Domino Applications. For example, you can have user-specific "Profile" Documents by setting the UNID to something like @Password("profile_" + @Name([CN]; @UserName)), and using either the Environment Variable approach or an inline HASH to get those NotesDocuments View/Index-free!

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!