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.

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!

Theory into Practice: Layers and Embedded Editors

I saw many good presentations at Lotusphere 2007, but one that was among the most stimulating to my imagination was the one produced by Nathan Freeman and Chris Blatnick.  Since then, they’ve both done some great work on their blogs using UI features I hadn’t used before, particularly layers and embedded editors (Chris’s blog is down right now, so I can’t link to more of his interesting work).

Anyway, one of the challenges I face after a conference is taking the ideas that get sparked during sessions and implementing them in the work I do.  Often it’s easier just to slip back into my standard design toolbag.  But when I saw these things in action, I immediately knew I had a use for them that wouldn’t just be showing off some new skill for the sake of trying it out.

Here’s the situation.  I am designing a database to track diversity requests and related workflow.  Requests can come from a variety of different sources which we generically call “companies.”  The design specifications called for the diversity administrator to enter a new company document with some basic information, then create a new request document, select the company, and then begin the workflow.  This is a classic example of the design needs driving the business process.  We need the company information so that the users don’t have to enter the same data multiple times (as the same company asks for different data, for example).  However, the users aren’t particularly interested in the “company” document; they are interested in the request.

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.

Writing to the Document Universal ID

This isn’t so much a “show-n-tell” as a description of how a feature can be used.

To me, one of the more curious aspects of the NotesDocument object is the fact that the UniversalID field is read/write. For a long time I wondered why anyone would want to write to the unique identifier. It seemed incredibly dangerous! If you weren’t careful, you could end up with duplicate IDs, and that could play all sorts of havoc. I was really shocked that Lotus had left that property writeable.

Then, one day, one of the users of a client-facing Quickplace deleted the welcome page. As you know, domino databases can generate fairly ugly URLs that include the document uniqueID. This QP was no exception, and numerous users (both internal and at the client site) had saved the site as a favorite. All of a sudden, their favorites stopped working.

You can see where this is going. I was able to get the URL that some users had saved, recreated the welcome page, and then ran an agent to give it the same universalID that the former page had. Our problem went away.

And I was very glad that Lotus had made that property writeable.