Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs







Recent posts

Thu 17 Sep 2020

Exciton Boost - WYSI(hopefully)WYG



Tue 15 Sep 2020

Exciton Boost - Formula(s) for success



Tue 15 Sep 2020

Pushing harder at the limits of formulas


September, 2020
SMTWTFS
  01 02 03 04 05
06 07 08 09 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30

Search the weblog





























Genii Weblog

Grid computing - an interesting challenge

Mon 8 Dec 2003, 09:41 PM



by Ben Langhinrichs
A customer has posed an interesting challenge, and I am playing with different ways to accomplish what he wants using our Midas Rich Text LSX.  He is looking for a dynamic table which represents a number of other documents, but his users want to be able to make changes to this one document and the changes reflected in all the other documents.  This "grid control" is a more grandiose version of what can be done in Notes 6 to a small degree with in-view editing, except with more control and with an R5 client as well as a Notes 6 client.

Now, I am under a bit of a time crunch here, but I want to experiment with the best way to do this.  Here are a few options, but I am trying to keep my head open to other alternatives as well:
  1. Create a table in rich text and let the user edit the cells, then push back the changes based on position or cell values:
    • Pros: Easy to create, low overhead, very flexible
    • Cons: Users can fiddle with the table, deleting rows for example, or can alter the key value
  2. Create a document with a stored form, and have the individual cells actually contain fields, then push back the changes on any document as it is modified
    • Pros: Tight control over what can and cannot be modified.  Possible to add a Save/Revert mechanism.
    • Cons: Lots of fields may be required, and no easy way to clean them up from UNK table.  Also, may be problems with signing scripts appropriately.
  3. Create a document with a stored form, and have each document have its own table, so the key can't be changed and any table alteration will simply cause that document to be left alone.
    • Pros: Medium control over what can and cannot be modified.  Possible to add a Save/Revert mechanism per document.  Also, no limit to rows because it isn't a real table.
    • Cons: Fewer fields, but way more tables.
  4. Some other choice I haven't considered yet.


I plan to use the Pinnacle East sample database, which some people may have seen used in my Lotusphere demos, and I'll try to implement all three solutions (and any more that occur to me) within that one database.  If it works well, I'll publish it as a sample on our website.  If it goes badly, well, I guess that is the risk of taking a challenge publicly.

If any of you have ideas of how this could work, or would like variations that would make sense in your business, feel free to post of send me e-mail, but if you want it done for this demo, send it quickly.

Update 1) I now have the selection working and it creates a tabbed table with the appropriate information, then takes changes and pushes them back.  Essentially Option #1 with a bit of flash.

Copyright 2003 Genii Software Ltd.

What has been said:


79.1. Tony Campbell-Cooke
(12/09/2003 06:39 AM)

Sounds very similar to my last project using Midas.

The ideal was that users should have a single document containing tabular data, and that they should be able to edit this directly. However, they also needed to report on individual rows within some of the tables. I quickly decided that direct editing of the table was too fraught with danger, in terms of uncontrolled deletions etc.

So I allowed additions to each table to be via a dialog box, making the entry in the first column into a hotspot, which would bring up an edit dialog box for that row. Each row was written to a backend document when added/edited, so the table could be easily rebuilt each time a row was added/changed. In addition, the backend documents could then be displayed in views for reporting purposes.

I also added the facility for batch entry, using a stored form, which allowed me to have validation for each field adjust to the new field name (this was done in R5).

Tony


79.2. Ben Langhinrichs
(12/09/2003 07:47 AM)

OK, so that is another basic approach really, and close to the one I use in the Walden sample. Thanks!