IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

I've been doing some experimenting to determine best practice recommendations about profile documents. They're problematic for use in web apps, granted, because their cache on the web server is very long-lived. For client applications, however, I don't see any reason to avoid them, and from a performance standpoint they have much to offer as an alternative to looking up configuration information using @DbLookup or @DbColumn.

The main problem you need to avoid in the client, is the creation of blank, duplicate profile documents when someone uses a replica that's not fully initialized (i.e. has not yet replicated the profile document). However, this is not hard to do.

First, @GetProfileField will never create a profile document. You can use the function on forms and so forth without worrying about creating bogus profile documents if the profile hadn't been replicated yet to a new replica. @SetProfileField will create a profile if it doesn't exist.

Profile documents are also unaffected by replication formulas. I'm sure this hasn't always been the case, but not sure when it changed. Again, with this change, there's less chance of the profile getting zeroed out by someone trying to use it in a local replica.

We also have ways in LotusScript now, to retrieve a profile document without creating it. Instead of db.GetProfileDocument(x) you can now do, for instance:

Set docProfile db.GetProfileDocCollection("MasterProfile").GetFirstDocument()

And then, of course, you have to check whether docProfile "Is Nothing" before you try to use it, but really you should be doing that anyway.

As for keeping track of your profile documents, some time back I posted a tool to view and control all the profile documents in an application.

To let someone edit the profile, you would want to do it in a way that can't result in someone creating a duplicate profile -- at least not without a fair warning. So you wouldn't just use @Command([EditProfile];...). Instead, you could use an action button or agent with code such as the following:

Option Public
Option Declare ' always use Option Declare
%INCLUDE "lsconst"

Const WINDOWTITLE = "Application Setup"
Const PROFILENAME = "MasterProfile"

Sub Initialize
     Dim session As New NotesSession
     Dim wksp As NotesUIWorkspace
     Dim db As NotesDatabase
     Set db = session.CurrentDatabase
     Dim docProfile As NotesDocument
     Set docProfile = db.GetProfileDocCollection(PROFILENAME).GetFirstDocument()
     If docProfile Is Nothing Then
             If db.CurrentAccessLevel < 6 Then
                     Msgbox "Only the database manager may create the setup document.", _
                     MB_ICONSTOP, "Application Setup"
                     Exit Sub
             Else
                     Dim result%
                     result = Msgbox({Warning! Setup document does not exist. Do you want to create one?


If one already exists in another replica of this application, it will cause problems.}, _
MB_ICONEXCLAMATION+MB_YESNO+MB_DEFBUTTON2, WINDOWTITLE)
                     If result = IDNO Then
                             Exit Sub
                     End If
             End If
     End If
     
     wksp.EditProfile PROFILENAME
End Sub

Come to think of it, I guess you could do this using a formula if you used @GetProfileField first to check whether the thing existed. To check whether a profile document exists in formula language:

@GetProfileField("profilename"; "$Name") != ""

So to integrate this into a "Edit Profile" action:

PROFILENAME := "MasterProfile";
@If(@GetProfileField(PROFILENAME; "$Name") != "";

       "profile exists - continue";

@UserAccess(@DbName; [AccessLevel]) = "6";

       @If(@Prompt([YesNo]; "Application Setup"; "WARNING! You are about to create a new setup document, which will be a problem if there's already a setup document in another replica which hasn't been replicated to here yet. Do you want to proceed?");

               "";

               @Return("cancel")

       );

       @Return(

               @Prompt([Ok]; "Application Setup"; "Sorry; only a database manager can create a setup document.")

       )

);

@Command([EditProfile]; PROFILENAME)

So, if we have some holdouts who are still not wanting to use profile documents in their Notes client applications, please comment -- why not?

Andre Guirard | 25 March 2009 06:54:04 PM ET | | Comments (12)

Search this blog 

Disclaimer 

    About IBM Privacy Contact