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)


1) Dynamic table on a Notes form
Keith Smillie | 3/19/2008 4:34:57 AM

Hi Andre,

Another alternative for dynamic tables, if you are using MS Windows clients, is to use the ListView control (MSComctlLib.ListViewCtrl). This can be programmed via LotusScript to produce very flexible and 'attractive' dynamic table.

Something like this:

{ Link }

2) Dynamic table on a Notes form
Nathan T. Freeman | 3/19/2008 7:11:38 AM

I believe Chris Blatnick and I covered this concept both years in the Lotusphere Interface Matters session. Don't use tables. Embed a view. So related information in the view. You have a complete event model available to you then, and you can even use InViewEdit to directly alter the data.

Trying to embed data content into rich text or HTML markup is SOOOOO R4.

3) Dynamic table on a Notes form
Wayne Sobers | 3/19/2008 8:08:17 AM

It's always good to see an alternative method of doing this so thank you.

I would hazard that a lot of time is spent by newcomers from other development platforms trying to achieve the same behavior.

It's unfortunate that we have to jump through hoops to get this type of functionality though, because these types of documents are the backbone of office processing.

4) Dynamic table on a Notes form
Andre Guirard | 3/19/2008 9:00:58 AM


If your approach doesn't crash performance, it's a reasonable choice from a UI perspective. I'm trying to find options for cases where the number of documents prohibits it.

We're actually talking about two different approaches here that use an embedded view. You said in-view editing, but Chris likes to use an embedded editor as well. You select the document from the embedded view, and you see it in edit mode just above or below the view. You make your changes, click another row, and the changes are saved automatically before the new row is opened. The advantage to this is that it lets you use all the regular Notes field types (ever tried to do a radio button field using in-view edit, for instance?). Unless the user can just type the information, in-view edit is an annoying way to enter data, always popping up dialogs. And if they can just type the information, give them a table in a rich text field and let them type! You can always pull the data into summary fields if you need to (the Catalog Entry form in my sample actually demonstrates this approach).

(Chris describes his approach here, with demo download)

One thing that concerns me about the embedded-view approaches, is that users are apt to think of the information they can see on the main document as a single unit. If they exit edit mode and abandon their changes, they might not expect the changes they made to the row documents to stick. This can be overcome with training, but that approach works best for people who use the application daily. Occasional users aren't going to retain this, I'm afraid.

Another issue is the click-counting thing. For high-volume data entry, it's nice if there's a way to move to the next row from the last field of the current row with one click, preferably the Tab key. It's not obvious how to get focus into an embedded view using the keyboard (I'm not sure you can), and there's not a way to launch in-view edit of a row using the keyboard -- which raises accessibility issues if that is the only way you provide to edit the data.

Keith mentions an active-X grid control (I assume it is). This is another way that can work in a lot of cases, though I don't like to use a platform-specific solution. Does anyone know of an applet with similar capabilities? Then we could maybe populate it on load (including keyword choices) and pull the modified data out on save.

It would be nice to have something built-in to the form editor. This will maybe be easier with XPages. But no matter what, there's still going to be some custom design work involved, to get the fields to behave the way you want them to. If you could somehow take a group of consecutive fields, draw a box around them, and say "repeat as many times as needed," it still raises issues of how you validate the data, how you sort the data, whether you let people delete rows or rearrange them manually, and so forth.

5) Dynamic table on a Notes form
Charles Robinson | 3/19/2008 9:26:16 AM

@2 - I believe Andre's point is... "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 issue I keep running into with embedded views is that I haven't found a way to use InViewEdit to create the first record in the embedded view. Ctrl+Click won't work unless there is at least one record in the view, so how do you add the first document? Do you create a dummy doc to prime the view?

6) Dynamic table on a Notes form
Andre Guirard | 3/19/2008 10:08:48 AM

Charles, I guess it calls for a view action.

7) Dynamic table on a Notes form
Nathan T. Freeman | 3/19/2008 11:17:34 AM

"There's not a way to launch in-view edit of a row using the keyboard "

F2. Just like Windows.

(Andre adds: Correction noted. I still don't see a way to get focus into the view, though)

8) Dynamic table on a Notes form
Betsy Thiede | 3/19/2008 12:27:50 PM

I'm always fascinated with Dynamice tables and have even had to use them in a profile document. This looks really great Andre.. I can't wait to try it next time I have a need.

I haven't used my code in along time. I opt for HTML for the "drawing" of the table..That has usually met my needs and alot less code then the way I wrote about..

But your user interface seems very convenient.

Thanks again for sharing..

9) Dynamic table on a Notes form
Doug Finner | 3/19/2008 8:30:18 PM

I tend to stay the heck away from dynamic tables. I have yet to build an app that 'needs' tabular data where I haven't had to eventually analyze the stuff in the tables. RT or multi-value fields make it pretty much impossible to answer the question 'what's my oder rate for item X over the last Y months?' I'll take the performance hit and let each line item be its own document.

I'm a big fan of the embedded view/editor combination - neat, clean, powerful.

10) Dynamic table on a Notes form
Dadoo | 3/20/2008 6:55:11 AM

Very Very good,

i will try to modify this example in order to add the interaction with a separate document functionality.

While add/modify each line i add/modify the related item document.

The only thing is that, i suppose, to change the agent "redrawTable" in order to cycle on the document and not on items.. if feasible and possible.

What do you think about this, in particular for very large number of documents ?

- in my situation 100 Order documents for each day with an average of 10 items for Order document!

- i include another "problem": in my case, i have a description item as free-text...and the user can insert a very large number of characters !

11) Dynamic table on a Notes form
Nathan T. Freeman | 3/20/2008 6:23:30 PM

"in my situation 100 Order documents for each day with an average of 10 items for Order document!"

1000 changes over, say, 10 hours? Should be no problem whatsoever. I would expect performance questions if you were doing maybe 10 times that number.

12) Dynamic table on a Notes form
Sasa Brkic | 4/4/2008 3:54:47 AM

@9 - I agree with Doug, doing any kind of reporting is much easier with regular documents and fields.

I use embedded view/editor combination a lot, but I do have a problem - how to print this kind of documents? The embedded view won't autofit vertically, so I end up creating a document on-the-fly and putting my "order items" in a dynamic table.

Is there any better way of doing it?

13) Dynamic table on a Notes form
Peter James O Bernante | 6/9/2008 12:02:24 AM

Hi Andre,

This is a clever way to create dynamic tables. I'm applying your technique in my applications.

Hi Keith,

Your alternative is brillant! do you have a sample application that uses the List View Control? i find it very interesting, but i couldn't find a way on how to implement it.

This would help a lot.


14) Untitled
Edwin | 3/26/2009 10:33:26 PM

Hi Andre

I'd like to ask if this method can overcome the 32K limitation of Text field size, cause I found each column for the order item is a text field with multiple value list saved in the order document.

Another question is how we can extract/export the order items, do you think is it possible?

Thanks & Regards

15) Link is broken
Jitendra Sachdeva | 5/21/2009 1:29:01 AM

Hi Andre

Link to dynamic table article is brocken.

Correct link is { Link }


16) List view control
Ravikiran Kodali | 9/21/2010 3:27:28 PM

@13 This might be of use for List view control

{ Link }

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact