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

One of the common bottlenecks to performance is the tendency to treat Notes as if it were a relational database, resulting in large numbers of documents that each contain a few fields. For instance, an order processing system might have an "order" form and a "line item" form, with ten or so line items as a responses to each order.

Notes applications tend to get better performance if there are fewer documents, so we'd like to combine these into a single document that has the general order information and the line items. The problem is that Notes doesn't include a dynamic table UI object, especially not one whose cells have all the features of Notes fields -- getting values from an @DbLookup and so on.

You can, of course, choose an arbitrary limit -- say, 20 rows -- and create a huge table on your form with a field in each cell. This is difficult to maintain since you have so many copies of everything, it has a lot of blank rows when you print it out, and having so many fields is almost as bad for performance as having lots of documents -- maybe worse, depending on average number of rows used versus available.

Various people have come up with ways to have a variable-length table of data on the form. The ones I commonly direct folks to are Betsy Thiede's Dynamic Tables Article in The View (you can download the sample database free even if you're not a subscriber) and the Domino Design Library Examples which includes set of design elements top copy over and then add your own stuff.

In both of these cases, the editing happens one row at a time in a dialogbox, and the image of the table is updated when you click OK -- but how? Betsy uses the LotusScript rich text classes to create a table, then saves, closes and reopens the document. This can be improved by reopening without saving as described in the Update rich text tip. The problem with this is that the user may like to edit the table multiple times in an editing session, and in a database with performance problems, often reopening the form can take some time because of all the lookups that are happening.

The Design Library Examples has a sample form that uses a table displaying one multivalue field per column with newline as delimiter -- the problem here being that if some of the data wraps, the whole table gets misaligned.

There's another way that I developed some time back; it takes advantage of the fact that you can programmatically import HTML into a rich text field. I've created a sample application that has just the basics -- a simple order form -- to show how this works. I'm using a variant of the row-editing dialog from the Design Library Examples. I prefer this to other row-editing dialogs because it was designed by counting clicks. I'm going to compare it with Betsy's version (sorry, Betsy!) where to edit a row, you click a button (1), you are prompted for which row to edit, you select the row (2) and click OK (3), that row is displayed, you make your changes and press OK (4). That's four clicks of "overhead" to get where you can edit the row you want, besides the editing itself. Then if you want to edit another row you click the Modify button again and repeat all that. I wanted to have a UI where you click a control on the row and you are editing that row. And, if you want to go through the whole table, you can do it without closing and reopening the dialog. In fact, the way my dialog is designed, you can go forward and back through the rows using Tab and Shift+Tab -- just as you could if they were cells in a regular table. So to edit one row, you click the button on that row (1) to launch the dialog, do your edits, and click OK (2). If you're filling out the whole table (as you would when composing the document) switching rows takes only one click -- the tab out of the last field to create a new row, or a click on a "next row" button.

Table row editing dialog

If you want to play around with this database, it is attached. The Using document gives detailed instructions how to set this up to edit your own information in tables.

Andre Guirard | 19 March 2008 04:00:00 AM ET | Man-Cave, Plymouth, MN, USA | Comments (16)

Search this blog 


    About IBM Privacy Contact