dominoGuru.com
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-@DBLookup
s. 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:
- Form: JavaScript Library Document|jslibrary
- Field: content - Rich Text.
- Content Type Form Attribute: text/javascript
- Agent: Summary|summary
- 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)
- 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!