When Notes table data doesn't play nicely with others
Fri 3 Sep 2021, 08:51 AMTweet
by Ben Langhinrichs
Copyright © 2021 Genii Software Ltd.
What has been said:
1127.1. Wayne (09/03/2021 06:40 AM)
A multi column list box would have sorted that issue out a long time ago.
1127.2. Ben Langhinrichs (09/03/2021 09:13 AM)
Well, yes and no. It is worth noting that the field type on the form doesn't necessarily translate well to the data type on the document. I could have a list box or radio button or text field or combo box or whatever on the form, but the data on the document is still a text list (multi-value text field), even if it only has a single value. When accessing via REST API or migrating via JSON, CSV, or whatever, the only thing that matters is what is stored on the document. So, a multi-column list box would probably be stored as a multi-value text list with delimited values. Still a mess to access or export, though better at keeping the rows together.
1127.3. Richard Pajerski (09/03/2021 01:32 PM)
I can say I've implemented the first three methods you list in a number of production applications. :-) They each work with varying degrees of benefits/drawbacks. I tend to use option 3 the most since it seems to offer the highest degree of flexibility (formatting, interacting, auditing, searching, etc.).
Two other (more exotic) ways of using tables in Notes:
1) Embeddable Java applets (Swing JTables in the applet container, not the Notes embeddable Java view applets). They're impractical though for a number of reasons including the difficulty of developing and integrating a good Java UI and issues around storing data (for editable tables). They'll also probably be outright impossible to use after the next JVM upgrade, since applets have been deprecated in recent JDKs.
2) Eclipse plugin, using SWT table widgets. Similar usability issues as applets but with the additional burden of the Notes plugin architecture.
Looking forward to your upcoming post.
1127.4. Wayne (09/03/2021 11:26 PM)
@Ben, I agree on the issue of field types. However, the developer could convert items to text format before display. And, yes, it would be limited in flexibility, but it would still be miles ahead of what has to be done now.
I don't have actual figures but I would guess that thousands of man hours have been lost trying to figure out how to get something to work - and look reasonably good.