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

A table on a table.We've been having a discussion internally about why it's not a good idea to put a rich text field in a table cell while designing a form, and the question was raised, do Domino developers know this?

So, just in case, here's the official line on putting a rich text field in a table cell: don't.

Tables generally are funny things; not everything can go into a cell. We've been gradually extending capabilities in this area -- for instance, you didn't used to be able to put a subform or (I think) a section in a cell, and now you can. But there are still some things that don't work in that context -- layout regions, for instance. If there's something you can't have inside a table cell, you can't have it inside a rich text field that's inside the cell, either.

So you would find that rich text content which is valid in other contexts can't be put into your field. You maybe can't inherit some rich text from another document that has its rich text field not in a table cell (or for that matter, inherit the whole document including the form, like the forward function in mail). There might also be some problems with margins (Can anyone with relevant experience elaborate?). Displaying the same rich text sometimes in a cell, and sometimes not in a cell, might not work totally as expected (e.g. if you have different Notes and web forms).

It also limits your ability to program tables in the rich text, because when you save a document that contains a table inside a rich text field that's inside a table, it gets treated as a nested table. The NotesRichText... classes don't deal with nested tables, so they can't even see this one. If the code that operates on the document is in a view agent or server agent, you wouldn't think that would matter, since these methods of accessing documents don't care about the form design. But it does matter in this case, because when you edit and save the document manually, the table is flagged as "nested" in the rich text data.

This particular limitation might not matter to you -- I have a feeling that applications that try to parse out data from user-entered tables are fairly rare -- but it's worth remembering.

Incidentally, no matter where your rich text field is situated, you can still get all the information from the document using DXL.

Andre Guirard | 1 May 2007 01:01:00 AM ET | | Comments (11)


1) Pass-thru as well...
Tim Tripcony | 5/1/2007 2:25:47 AM

I've also had problems displaying pass-thru html in a tabbed table, although I haven't had occasion to try it in 7.

2) Strange advice
Nathan T. Freeman | 5/1/2007 6:26:31 AM

So Andre, basically you're telling us that there are a bunch of known limitations with rich text that we should work around.

It's one thing for a business partner or customer to say this, but for IBM? It sounds like you just wrote up a design center for Notes 8.5. :-)

After all, given the number of things that we can ONLY do in the context of a table, such as horizonal splitting, or background color/graphic control, or proper border handling -- table cells are an absolute requirement for layout & styling management in Notes.

Heck, the first thing I do when I create a new form is put down a full-window-width table with no borders! Because this is the only way to establish an on-screen border control that gives me buffer space for the overall form, yet still allows fluid designs. EVERYTHING goes inside a table cell, which ensures that EVERYTHING fits into a flowing margin set that has an outside border against the screen edge that adjusts to resolution. What else does Notes provide for this? 99% relative right margins? They don't cut it.

Not to mention that you can't do background color controls in RT fields, or use a native OS style. So if the RT field is not the ultimate purpose of your form (like it is in the mail message) then there's no good presentation model available that doesn't require a table.

Even the Contact form in 8 puts the RT field in a table cell.

3) *doh* That explains it!
Charles Robinson | 5/1/2007 8:50:28 AM

"There might also be some problems with margins (Can anyone with relevant experience elaborate?)."

I did an app for my users to let them create form letters. They wanted to be able to vary the fonts, so I gave them a RichText field. For layout reasons, I put it in a table. When the users produced the form letter from the template I would grab the template RTItem, copy it to a new RTItem, then parse through the copy and replace the placeholders with actual data. Then I would send it on its way.

I noticed very quickly that the left margin on the RichTextItem was always off. No matter what I did it had an extra 0.5" to 1" left margin. I ended up dropping the RichText field outside the table structure and it worked perfectly.

Thanks so much for the explanation. I chalked it up to another Notes quirk, which it sounds like it is, but it is good to have a better technical understanding of what is going on.

4) re: Strange advice
Andre Guirard | 5/1/2007 9:14:04 AM


"Don't" is the beginner story.

Knowing the limitations, you might choose to do it anyway because of the other benefits you list. It's useful to have this kind of feedback -- thanks.

5) Definitely can be margin issues. (second try)
Jerry Glover | 5/1/2007 9:49:34 AM

I remember running into this many years ago when using a typical side to side label-data table arrangement and needing an RT field. Later, when displaying (non-edit mode) outside a table context, the RT field retained the (large) indent. Oops!

You then learn to use the label-above layout for the RT field and keep it outside of the table. But I have continued to use RT fields on occasion as long as it was within full-window-width table cells.

As Nathan says, it's hard to totally avoid when trying to create nice-looking UIs. e.g. You might end up with a tabbed table form with a lone RT field hanging out below everything else and out of context with other relevant data/fields that are otherwise grouped on a tab in the upper portion of the form.

6) well ...
John Head | 5/1/2007 12:07:26 PM

Sounds like you just created a major, high item fix Andre. Putting rich text fields inside a table cell is pretty much a must in Notes. It is the only way to get any control on the form to display things besides layers. And, what about when you need rich text fields side by side with a fixed height and width?

Thank you for pointing out the issue. Please also make this a high priority fix.

7) I’ve never had much trouble with RT fields in tables
Ben Langhinrichs | 5/1/2007 3:28:31 PM

Actually, it has been an excellent source of revenue over the years - selling our Midas Rich Text LSX to fix margins, deal with nested tables, etc. etc. So, by all means, don't fix the problems. And please, don't even think about supporting nested tables, even if they have been in the product since R5.

8) re: I’ve never had much trouble with RT fields in tables
Andre Guirard | 5/1/2007 6:14:32 PM

funny guy.

9) It is a shame
Ralf M Petter | 5/2/2007 2:28:44 AM

It is a shame, that 3rd party utilities can handle Rich Text so much better then the ls script classes. I hope IBM will enhance Richtext support in lotus script and java in future versions of Notes/Domino. An alternative will be to complete DXL support for rich text so i can make the manipulation in DXL. And it would be very helpfull if we can make backend changes to rich text visible without saving and reloading the document.

10) heureka ...
Ulrich Krause | 5/2/2007 11:14:20 AM

could the richtext-in-a-table problem be the reason, why we do not have a LS method to insert RichText into RichText?

11) re: heureka ...
Andre Guirard | 5/2/2007 2:51:39 PM

> could the richtext-in-a-table problem be the reason, why we do not have a LS method to insert RichText into RichText?

It's probably one of the reasons; it's hard to say exactly what all factors might have made it more difficult to implement insert than append. More generally, the reason is "we don't have time to implement that for this release" when the rich text classes were originally implemented, and we also haven't had time to do it since. Competing priorities, as always.

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

Search this blog 


    About IBM Privacy Contact