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: Computing Frame Contents

Frames on the web are out of style, but they are invaluable in Notes programming.  We tend to use a frameset with a single frame for our web applications because of the flexibility it gives us.  One of the things it allows us to do is load different content into the frame in different situations.

In my previous post, I talked about how easy it is to make a database accessible to a BlackBerry.  One of the things we wanted to do, though, is to differentiate what a BlackBerry user sees on first opening the database vs. what someone sees using a browser.  To do this, we computed the content to load into the frame depending on the value returned by @useragent.  So I went into our Frameset and got the frame properties dialog box up.  On the Basics tab, next to the Content Value textbox, I click the @ button to calculate the content.  A dialog box like the following appears:

This dialog box allows you to compute 3 things:

1. the type of element (in this case, a view for a BlackBerry and a form otherwise);
2. the database where the element can be found (blank means the current database);
3. the identity of the element (the view name and form name to correspond to #1).

The power of this feature is limited only by what you can do inside an @if statement.

Astonishingly simple

I don’t have much time to write today, but I wanted to post something about my first foray into programming for the Blackberry.  I took an existing phone directory application and had it working well for the Blackberry in less than an hour!  Domino (as usual) does much of the HTML work for you, and you can detect when a BB is asking for the page so that you can provide special HTML, or even a specific form.  For example, the form formula I use to serve a different form to the BB is:

@If(@Contains(@GetHTTPHeader(“User-Agent”);”BlackBerry”);”BB-Personnel Information”;”Personnel Information”)

The Blackberry specific form is very simple with no tables and no unnecessary graphics (all those hours designing terrible UIs in version 4.6 have finally paid off!).  If you have been hesitating at all, I encourage you to take some baby steps into developing for the Blackberry, as I have.  It is much easier than I ever imagined.  I’m sure it can get trickier and more robust, but it’s nice to get something going so quickly.

For more details, start here.

Formula Language vs Lotusscript

Like a lot of developers, I tend to you formula language for simple task and Lotusscript for more complicated tasks. I always figured that–at least for simple items–formula language was optimized and thus faster.

Yesterday, though, my tester commented that a particular action–a typical bulk approval–seemed to be running more slowly at one level than at the previous level. The previous level had a fair amount of logic and new field creation, so that agent was written in Lotusscript. This final approval was very simple, and so I had written an agent like the following in formula language:

FIELD AppDate:=@now;
FIELD Approver:=@name([cn];@username);
FIELD Status:=”Approved”;
select @all;

The agent ran on selected documents. Since it was slow, I quickly wrote the equivalent in lotusscript:

Option Public
Option Declare
%INCLUDE "lsconst.lss"

Sub Initialize
   Dim sess As New notessession
   Dim db As notesdatabase
   Dim dc As notesdocumentcollection
   Dim thisdoc As notesdocument
   Dim nextdoc As notesdocument
   Dim goodcount As Integer

   Set db = sess.currentdatabase
   Set dc = db.unprocesseddocuments
   Set thisdoc = dc.getfirstdocument

   If dc.count = 0 Then
      Messagebox "Please select at least 1 recommendation", MB_ICONStop + MB_OK, "Bulk Approval"
      Exit Sub
   End If

   Do Until thisDoc Is Nothing
      Set nextDoc=dc.GetNextDocument(thisDoc)
      With thisDoc
         .MCAppDate = Now
         .MCApp=sess.CommonUserName
         .status="Approved"
      End With
      goodcount=goodcount + 1
      Call thisdoc.Save(True, False)
      Set thisDoc=nextdoc
   Loop

   Messagebox goodcount & " compensation recommendations approved."  , MB_ICONInformation + MB_OK, "Bulk Submit"
End Sub

Sure enough, this simple Lotusscript agent ran much faster than the formula equivalent; my tester estimate 5x faster. The question is why? Is formula language simply not as fast as I thought? Is the overhead of the progress bar that automatically appears when users run a formula language agent so high that any optimization is overwhelmed? I’m not certain, but the performance upgrade is noticeable enough that I’m not likely to try to write even simple agents in formula language anymore.