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

Style 'setting' of a view columnThe image at the right looks deceptively like a property of the column -- but it is not. The type of data stored in a column is a non-concept, because data are not stored in columns in the view index. Data are stored in rows. The type of data stored for a column for a particular row, is determined by the formula of the column. It can be different for different rows.

It therefore makes sense to specify formatting for numbers (in case the value on a some rows happens to be a number) and dates (in case some rows contain dates) and names (because it might be a username string on some rows, or might pick up a name from another column). Because of the design of your application, you might know (or hope!) that all the values will be numbers, but that is not a property of the view design, but a statistical attribute of your data. Think of the Style field not as a property, but as a navigational control allowing you access to these different sets of formatting options. It is not the "datatype of the column," because no such thing can exist. Imagine instead of this field, a second row of tabs for number options, date/time options, and name options. It would've prevented misunderstanding if we'd done it that way at the start, but c'est la vie.

To get a correct picture of what's going on, one must think of the view's contents, and its formatting for display, as two completely separate things. If a column formula returns a number value for a particular document, then that exact number is stored in the view index; if a date/time value, that exact date/time is stored. For instance, suppose the formula for the Amount (K) column is TotalAmount/1000. If TotalAmount contains (the number value) -14506, the view index will store -14.506, expressed in binary floating point, to within the limit of accuracy of that representation.

Now suppose the settings on the "Advanced Format" tab of the column properties, specify two decimal places and parenthesis around negative numbers. How does this affect the value stored in the row entry? Answer: not at all. The sole purpose of these settings is to determine how the value will be displayed on someone's screen. -14.506 remains -14.506, even if when you open the view, you see "(14.51)" (or for some users, "(14,51)"). The column value retains whatever precision it had from the formula that calculated it (or the exact value from the original field, if it was a field column instead of a formula). It doesn't contain the character "(", or ".", or any characters. A number is the same no matter how you choose to display it.

You may be thinking, "Why does it matter, you picky Andre person?" Apart from an understanding of how things work being generally important to being able to predict what your design will do, there are three common situations where the difference between storage and presentation has important effects.

1.        When users with different formatting preferences use the view, the values are displayed using their local settings. As mentioned before, different users of the same view may see (14,51) or (14.51) depending what they have chosen to use as a decimal point character. Similarly with date formatting; the order of the year, month and day can be different for different users. This is highly desirable. It really is. Please don't try to defeat this useful feature by using @Text in the column formulas to convert the values to strings. If you do, you will confuse users, and make your data sort incorrectly (because 9 < 10 but "9" > "10").

2.        When you read the view data using code, for instance with an @DbColumn formula, or Columnvalues in LotusScript. These functions ignore formatting, going straight for the data. This is important both when reading the data, to realize that the value you read might not be exactly what's displayed in the view, and when specifying a lookup key, since it will only find documents that match the key exactly -- not that just look like they ought to match the key.

3.        Likewise, if you sort or categorize the view, you may see unexpected results if your column values have more accuracy than they display. For instance, suppose you sort ascending first by a column containing date/time values, then by a Name column. You might expect to see 04/23/2008 Alvin before 04/23/2008 Sam, but if Alvin's date/time is really 04/23/2008 4:15 PM and Sam's is 04/23/2008 7:40 AM, then Sam will list first despite your having used the formatting options to hide the time value. Similarly, suppose you categorize a view by date values that also contain a time (which is hidden). The date (the displayed value) may be the same, but the exact date/time is likely to be different for each document. This results in a view containing 50 categories for 04/23/2008, each containing one document, because while the category headings may look the same, they are not in fact the same. If you really need the entries to have limited precision, use the column formula to return an entry of limited precision (E.g. by using @Date(fieldname) instead of just fieldname ).

Andre Guirard | 23 April 2008 07:30:00 AM ET | Home, Plymouth, MN, USA | Comments (1)

Search this blog 

Disclaimer 

    About IBM Privacy Contact