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.

Preventing duplicate submissions

The Situation: We have a database for performance reviews. Reviewees can solicit reviews in the database and reviewers then have the option of creating unsolicited reviews. We want to prevent reviewers from creating duplicates (either two unsolicited for the same person or an unsolicited where a solicited exists already).

The Challenges:  We have mid-year and end-year reviews in this database, so the same reviewer can write one eval in each cycle per reviewee.  If a reviewer tries to create a duplicate evaluation, we have to present the reviewer with the choice to open the existing copy or just to end the creation process.

The Solution:  Checking for duplicates was fairly simple: we have a view with a key of the year, the reviewee, the reviewer and the cycle.  Before document creation, we do a lookup to that view and if the document doesn’t exist, we create it.  The trickier part was how to handle opening it after a prompt.  We decided that the function that creates the document would return a variant string array.  The first entry in the array would hold a message and the second entry would hold a Unid.  If the document is created (no duplicates), the message is blank and the Unid is used to open the document in the UI.  If there is a duplicate, the message returned indicates that a document already exists.  This message is placed in a message box to prompt the user how to proceed.  If they want to open the document, it uses the Unid of the document it found in the view; if they just want to exit creation of the document, the script stops.

The Advantages: We found we could also return error messages or other status messages using the same architecture.  In such a case, if the 2nd return value is empty, the calling code would end after the prompt.

The Disadvantages:  Implementing this was a bit trickier on the web.  We return much of this information in the URL of the document so that the web client can then perform the prompts.  We have less control over message boxes on the web, so we had to re-craft the message depending on client type.  On the other hand, having the Unid already made opening the document a simple URL rather than using a WQS to go get a document.

Overall:  We’ve found this to be a pretty flexible design.  If we ever needed to return a third (or fourth, fifth, etc.) value, we could easily add that to the return array without breaking existing code.

Coding for client and web

At my company, we have been mandated to code for both client and web use.  As I talk to people, this is becoming more common, but there are many challenges.  To me, one of the biggest challenges is the amount of stuff that has to be done twice.  We all know that Notes can produce web applications “out of the box,” but they are, frankly, terrible:  page refreshes abound, layout is difficult to control, and the Java applets that were cool when they first came out aren’t useful to most of us today.

One area I have been focussing on is the outline.  We have a few applications where the outline changes regularly (I think that is fairly unusual for an application, but I could be wrong).  To maintain both a client and web version is a nightmare, so I wrote an agent to generate HTML based on the outline.  This works well for simple outline entries like links, but it forces us to avoid using formula language which may be supported on the web but which I don’t know how to translate in a lotusscript agent.  So, for example, instead of writing an outline entry with an action of @command([compose];”MyForm”), we use a named element of Form type that opens MyForm.  Both work, but I think most developers think more like the former than the latter option.  I’ve got an idea on how to make even this work…if I figure it out, maybe some magazine will want to publish it.   If not, I’ll share it here.