It's been a long time since I've posted here. Sorry about that. We have been extraordinarily busy lately. That's a good thing but it's only just now that I have, however temporarily, been able to get my head back above water.

Henry and I have been particularly busy with the rebuild of an on-line insurance quoting and management system. The story is terrific but I'm not sure I can talk about it right now.

Technically speaking, the project is even more interesting.

Insurance rating, if you haven't spent much time with it, is surprisingly complicated. Take an Auto policy, for example. It's not always so simple as just you and a car. Families have multiple cars and multiple drivers. The rate you pay is influenced by all kinds of things including the driving records of all the folks on your policy, their ages, which cars they drive and a laundry list of other factors.

Trying to collect all this data--from many sources--into a single easy-to-use interface that is fast and attractive is really quite a challenge. We have come up with what we think is a great solution (wish I could show it to you right now) that uses all kinds of web development tools: HTML, Javascript, DHTML, AJAX, XML, Domino Agents...you name it, it's probably in there but the cool thing is it's all pretty transparent to the user.

Along the way, and based on a great suggestion from the lead developer at our client, we came up with a very interesting technique for building web applications that involve multiple sets of the same data. You know, like mutiple drivers, or vehicles, or buildings.

The challenge is in maintaining all the data-collection fields. Let's say you're collecting information about buildings. You need fields for address (street, city, state, zip), phone numbers, age, construction, and the like, but there are probably a lot of other things you'll want to know. For instance, the name, address, and contact information for the management company if there is one. Is it owned or leased? Single occupant or multiple? Is it heated? Do you store flammable or explosive materials there?

You get the idea.

There are a lot of questions that can be asked about any one building. But then, if you're talking about multiple buildings (think farm or manufacturing facility), you have to ask all those questions for each structure. This is nothing we haven't all built a hundred times before, and there are a number of solutions. The problem isn't so much building the table or whatever it is you're collecting all the information in, the problem is in maintaining it.

Let's say you need to be able to collect data on, oh, 20 structures. In a table, that means 21 columns (one for labels, 20 for data on each of the 20 structures). If you have 30 fields you need to maintain for each structure you have a total of 600 fields in your table. Not ideal, but not the end of the world, either. The problem comes in when you have to make changes to the fields, or to add new fields to the table. Any change you make has to be made 20 times. After a while, even small changes add up in terms of time and effort.

So, what if you didn't have to make every change twenty times? What if you only had to make it once? That was the idea we had (and solved).

We figured out a way you can, in a situation like I've just described, make a table in the Domino Designer which has just two columns (one for labels, one for fields) and the thirty rows of data, and to have that table automatically--programmatically--duplicated the 20 or however many times you need it to be, on-the-fly as your document is being loaded.

Let me say that again simpler:

You build a little table with one full set of fields; the code duplicates those fields over and over again as many times as your application requires. Tell it 8 and it makes 8. Tell it 20, it makes 20, with no more changes to the application than adjusting one variable.

It's really pretty cool. And, surprisingly fast.

You can see an example with three columns in the image at the top of this blog entry or, better yet, here's a simple example of it you can play around with. What you initially see is a typical form with three data columns. Notice, though, that simply by changing the number in the &cols= parameter of the URL you can change it to more or less whatever size you want. And, while there is some delay with larger numbers, even 50 columns comes up pretty quickly.

If you look at the underlying HTML you'll see there's not much there. It's just a two-column table that looks like this:

Before actually building this application (the real one, not the little demo here), we did some benchmark testing. We built a table with 10 columns and 100 rows. We filled the cells with fields, 1000 in all. Then we built some code that would build an identical table with identically-named fields except it would do it on the fly during the onLoad event of the form. We added some code to both forms to measure the time it took each to load. And, guess what? The dynamic form was significantly faster.

As you may imagine, there's more to all of this than I'm suggesting here. You have to load and unload data, for instance, which is not entirely trivial. But with some clever coding (thank you, Henry) it is quite do-able and, best of all, it makes day-to-day maintenance of the table quite simple. Instead of making changes on each of six or 20 or 50 columns, you make the change once and it automatically proprogates itself however many times.

With a little luck, I'll be able to show this to you at Lotusphere this year, and to go into more detail about the inner workings and benefits. In the meantime, I'll try to get back here again a little sooner and re-invigorate my blog. See you soon!

1. Rich Waters10/12/2006 09:43:14 AM
Homepage: http://www.rich-waters.com/blog/

There's a problem with the code in firefox, there's an error when trying to get a handle on the table:

var wt=tpd.getElementsByTagName("table")(0)

If you change this line to use [0] instead of (0) to reference the first element it appears to work.

2. Newbs10/25/2006 06:21:59 PM
Homepage: http://www.henrynewberry.com

Doh,

Thanks Rich,

I've been trying to figure that one out...

Newbs

3. Scott Good10/26/2006 08:30:28 AM
Homepage: http://www.scottgood.com

Rich,

Thanks for the fix...and Henry, thanks for making it in my example.

Scott

4. Ian Randall12/21/2006 10:11:20 PM

I tested it with 999 columns, it took a little time, but it worked.

I am impressed.

5. Erwin11/24/2009 05:48:37 AM

Looks promising, but is the code public?

6. Scott Good11/24/2009 07:22:24 AM
Homepage: http://www.scottgood.com

Sure. There's a link to code in the article.