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

You know those columns in your inbox that let you choose to display a different background color on a row based on who the email is from, and that show the "to-ness" icons that clue you in whether the email is to you, or you're just copied, and so on?

It's kind of confusing how this stuff works, and I've been looking into it recently. I decided to write it down here so I can look it up when I forget. Here are some relevant facts:

  • User-defined columns can use any of the display options. If you read the Designer help you might come away thinking that you can only use them for color columns. In fact, they can also be icons, or just display characters like a "normal" column.
  • They use a formula which is stored in text item (not formula datatype) in a shared profile document. Because of this, it is not possible to have different preferences for different users. It's user-defined in the sense that it's easy for an authorized end-user to edit the profile document and thus change the behavior for everyone -- not in the sense that one can potentially see a personalized value.
..............
  • The name of the profile document is a column property. All the user-defined columns in a view have to use the same profile document. If you enter different profile document names in different columns, you don't get an error message warning you of an incorrect configuration -- it just doesn't work.
  • The name of the item in the profile document is the same as the column programmatic name (in the Advanced tab of the column properties). You don't have to accept the default column name (which is of the form "$" followed by a number), but if you change the name, the new name also has to start with "$". This is not a general rule about column names -- it only applies to user-defined columns. If you enter a name that doesn't start with $, you don't get a warning -- it just doesn't work.
  • The formula for the column must be non-constant, because the indexer ignores columns with constant values. IBM uses @UserName as the formula for such columns, and that's misleading because it implies some personalization is happening, which as we have seen is not the case. There's no reason you shouldn't use @UserName -- it's non-constant, which is all we require. If you do put in a formula that returns a constant value, you are not warned -- it just doesn't work. Some functions you would think would be considered variable, like @Unique, are treated as constant for this purpose. Bottom line -- use @UserName, it's safe, but remember that it's just a placeholder -- not actually used for anything.
  • The value of the column is calculated by the server -- not by the user's workstation -- as part of the normal view indexing task (unless of course it's a local replica). Therefore, you can't do anything in the formula from the profile document, that you can't also do in a regular column formula. It's just more customizable -- not more capable in any way.
  • In particular, @UserName and other user-based functions, don't work any better than they would in a "normal" column formula.
  • Nor can you use @DbLookup or @GetProfileField or any of those other things people often want to do in a column formula and can't.
  • You can use @Now and @Today in these functions without causing the view to rebuild every time you use it, but this is just like using @ToTime("Today") -- you are fooling the indexer so that the view also doesn't rebuild when the row values of previously indexed documents become obsolete. Result: your view contains out-of-date information. User-defined views do not help you do anything date-related that you couldn't do with normal columns.
  • The server (or your workstation if it's a local replica) does notice when the profile document has changed, and rebuilds the view index. So your changes get applied right away to documents that were previously indexed. I believe this also means that view indexes may be rebuilt unnecessarily if you modify the profile document for some other reason. I'm not sure whether the indexer pays attention to the item modification time. My guess is not.
  • User-defined columns are slower to index than regular columns, but I think not very much slower. There's overhead in the setup for indexing, where the indexer has to read two notes (the view and the profile) instead of just the view note. But once it's got the formula in memory, I don't see why it should be slower to execute this formula on each document, than would a normal formula.

Andre Guirard | 28 March 2008 04:31:00 AM ET | Home, Plymouth, MN, USA | Comments (1)

Search this blog 

Disclaimer 

    About IBM Privacy Contact