Using the right tool for the job

We’ve been having a discussion internally among the Notes developers about how to best write hide-when formulas based on user roles.  There was a group who usually used @contains, but we have run into problems where the substring is Null, because then @contains always returns True.  I’ve always advocated using @ismember because it seems to be a more accurate function when I want to know whether or not a person is enrolled in a particular roll.

My supervisor, who is a brilliant coder, prefers to write hide-when formulas in this way:  write a formula for who should see the item, then make it a negative using the ! operator (and changing booleans as necessary).  I’ve always found this a bit difficult because my mind doesn’t work this way.  Also, I chafe at things like !@ismember when there is a function called @isnotmember.  I feel certain that the latter must be faster (albeit fractionally), and I find it easier to read.  I guess it’s just my feeling that we should try to use the tools given to us that are best suited for the task.

SNTT: Opening subforms quickly

This is a tip that has been around awhile, but it is so unbelievable that I wanted to share it in case you haven’t seen it.  In other words, this doesn’t originate with me, and I’ve forgotten where I found it originally.

As most of you know, subforms are slow. A form with multiple subforms is particularly slow, even if the subforms aren’t computed (which, of course, slows the loading of the form further). There is one easy way to make subforms load quickly: Put some lotusscript code–Any Code!–in the initialize event of every subform. We use something like this:

Dim fastOpen as boolean
fastOpen = True

If you have a form with multiple subform, this simple, meaningless code that does nothing makes a HUGE difference in load time. I have no idea why adding code makes the subforms load faster, but it does (at least in Notes 5 and 6). Give it a try!

Coding without Code

One of my goals as a developer is to write as little code as possible.  That’s a bit flip, but it’s true.  I try to code in such a way that it is easy to access, re-do, or re-use code so that when requirements change or get added, the amount of work is required is minimal.

One of the requests that came up last week was to add an email reminder to a database that would send an email to anyone who had not yet submitted a particular form.  The form exists in the database, and the administrator has a view that shows whose documents are outstanding.

When we first designed databases, we knew we’d be sending emails to tell people that documents were available as well as other sorts of reminders.  My design had 3 parts:

1. a form where the administrators selected the type of reminder, entered the content of the email, and set a date and time for it to be sent;
2. an agent that checked the dates and times of these documents and sent emails as necessary;
3. A designer only form that gave a name to the reminders and told the agents where to find the list of people to whom the email should be sent;

Item #3 is what allowed me to add the requested functionality without any code.  All I had to do was create a new document from this desinger form and give it a name (for the administrator to pick from the list) and tell the agent the name of the view where the list to send to could be found and the name of the field where the email address exists.  Once I saved that document, the functionality was immediately available:  no design refresh and no new code required.

Of course, all my code doesn’t come out this way.  But it’s so nice when it does!