Addressing Domino Web-based @DBLookup limitations with Rich-Text and Context Profiles

12/16/2007 12:42 PM by Chris Toohey

Author's Note: I was asked by a good friend for a solution to get around a problem that is probably more common than we may think: web-based comboboxes/select field-types requiring lookups to data in the application. This is, most of the time, done via runtime-@DBLookups. My good friend contacted me more due to the fact that, as this application has grown, he's running into the dreaded @DBLookup/32Kb limitations, and he's looking for a way to solve his problem while keeping an eye towards future database bloat usage.

Now, I'll take the time to discuss two approaches to solving this problem - as I see this as two issues, as well as use his real-world example as a grounds for showing the application of said solutions. And without futher ado...

Erskine has a problem. Actually, some would argue that he has two problems. He's got what should be a very simple web client-based Domino application that relies on the typical mock-relation categorization: secondary documents which are used to create linked-by-keyword categories for primary/main documents. The majority of us developers have done this time and time again, simple and good-enough solutions that get the job done and the given project off of your task list. The problem this architecture runs into, as anyone who has written large-usage applications can tell you: you either 1) get bulky, clunky (read: slow) load times as your combobox/select field-type needs to look up a view for it's keywords or - and more critical (and what spawned the need for this article) you start to run into @DBLookup limitations due to the sheer volume of data that you're returning.

Now, the ideal solution would be to replace the entire mechanism for said lookups - go with a more name-picker approach to selecting a keyword - but as we need to maintain the current application as well as the user expectation of it's functionality (read: users will run in fear from your boomstick-like AJAX-based namepickers and other widgets), we'll left with only a few options. Heck, only one really good option in my opinion, which is what we'll get to in this article.

First, let's recap the current application:

We have a simple Domino application, which uses a View element to store a collection of keywords for our primary documents via secondary documents. The primary document Form element does a runtime @DBLookup to a view to return a list of said keywords for usage.

Now, your typical developer will not generate their own markup in the view, such as this:

"<option value=\"" + datavalue + "\">" + datavalue + "</option>"

- but rather have a list of values in a given column and let Domino generate the option element markup for them. So, before you get any smart ideas, you can't bypass this immediate need of addressing the @DBLookup error by simply pruning the markup...

Author's Note: Also, something to consider, feeding a combobox element a list of values and expecting Domino to generate your content will result in malformed and difficult-to-work-with markup. For example, simply supplying a list of values (val1:val2:val3) renders the option element without a value attribute - making interaction via JavaScript a much more difficult ordeal...

What we need here is a solution that will allow us to create a bunch of usable markup in a way that we 1) don't have to worry about nasty lookup limitations and 2) we improve the performance of the current runtime-based lookup facility. To achieve this, we'll take a look at an earlier publishing where we used the ability to control a document's Content Type to provide us with some quick-and-easily-maintained functional content, and we'll use this methodology as the cornerstone of our solution.

For this new architecure, we will need the following:

1. Form: JavaScript Library Document|jslibrary
1. Field: content - Rich Text.
2. Content Type Form Attribute: text/javascript
2. Agent: Summary|summary
1. We'll want to loop through all of the Secondary Documents to gather our Primary Document keywords. Once we've gathered our volumous list, we'll format them for JavaScript usage (more details in the example)
2. Schedule this whenever you need to really, it'll run in the back-end and be used to generate our JavaScript Library Document

We write a simple scheduled agent, Summary, to query the Domino application for all of our secondary document keyword data. Once that list is gathered and the javascript generated and formatted, we create a new document using the JavaScript Library Document form, which will contain nothing more really than a Rich Text field, which is where we'll store our JavaScript. The JavaScript Library Document form will have it's Content Type set to text/javascript. Now, when the newly-created JavaScript Library Document form-based doucment loads, the JavaScript will trigger and update the combobox/select field-type with all of our secondary document-maintained keywords without having to worry about any silly @DBLookup limitations or resource-intensive runtime routines.

That's it really - except for the example which should tie all of this together (I hope). The only thing that you should need now is the syntax for our JavaScript - that we will use to first clear the combobox/select field-type options and then add our own - and the particulars on how to generate that JavaScript markup. Other than that, it's a matter of getting a download ready (which will follow the publication of this article) and you should be good to go!