Your Development & Design Resource
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
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
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:
- Field: content - Rich Text.
- Agent: Summary|summary
We write a simple scheduled agent, Summary, to query the Domino
application for all of our secondary document keyword data. Once that list is
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.