XPages brings a lot of really interesting technology and capabilities to the table for web (and for that matter, Notes) developers. In the middle of all that goodness, however, are some really basic things that are shockingly hard to do. For instance, modal dialogs from Server-Side JavaScript (SSJS).

From the research I've done, there is probably, possibly, pretty sure, MAYBE a way to do modal dialogs with Dojo. Well, sure, of course there's a way to do modal dialogs with Dojo. They're really easy...unless you actually want to do something like, for instance, gather any user input. As soon as you need to collect the first data point (other than, I suppose, the click of an OK button), things get harder.

Hard enough that I gave up on them right after I discovered detailed instructions which included having to load extra code onto the server. Maybe there's an easier way, but any idea that begins with requiring a customer to talk an admin into loading new code on their precious Domino servers is pretty much a non-starter around here..

Now, in fairness, I'm not a Dojo expert, so maybe there's a way to do it without server add-ins. If so, I couldn't find it. So, I rolled my own.

I don't know about you but the applications we build are CONSTANTLY needing dialog boxes users can fill out to update information with. REAL dialogs, with fields and options and choices, not just text-only dialogs for annoying our users. And, with XPages, we rarely write any client-side JavaScript anymore so I needed a solution that would work in Server-Side code.

So, I says to myself, "Self?," I says, "There has to be an easy way to do this with CSS." And, joy of joys, there is.

It's been a while since I last posted a Show-N-Tell Thursday item (and, yes, I know today's not Thursday but, well, whatever). Jim Sanders, one of our guys, came up with some really interesting numbers related to what is the fastest way to do custom searching of a Notes database with LotusScript. Below are Jim's findings...enjoy:

Recently a client has had the need to do a custom search routine in an existing Notes database. You've seen the kind where you build a dialog box which allows a user to choose various conditions they want to search for. Typically it runs something like this:

1. Prompt the user for what they want to retrieve.
   
2. Run the search using either the database Search or FTSearch methods.
   
3. Display the results.

Not a big deal until you need to also add on a custom export (say through Excel) in which you need to organize this lump of data into some criteria that has been predefined by the client. We all know that Search and FTSearch return (essentially) an unordered document collection. There are numerous ways of doing that kind of sorting. Heck, Teamwork has one built into a standard script library (TSFormulas) that we nearly always use. This library contains both our own document collection sorting routine as well as a lot of @Formula code re-written into script and some other cool stuff thrown in for good measure.

However, since we couldn't use that TSFormulas script library we were stuck coming up with a way to do this sort. The senior developer at the client was interested in using a sorted document collection object he'd pulled off the net a while back. My idea was to dump the entire document collection into a folder (using the handy little PutAllInFolder method of the DocumentCollection object) and let the folder do the sorting for us. Since we're interested in keeping performance as fast as possible we did a head to head comparison just to see who might come out on top. Using the same database and search criteria (returning 4,981 documents via the search) as our test bed and utilizing the new profiler capability of the R7 client we have a winner.

Call this a Blinding Flash of the Obvious. I don't know about you, but I find I regularly pop into the Notes Designer Help to check our a method or verify syntax or do, well, something.

The Designer Help is excellent except for one silly little oversight: Every time you open it up, it starts at the "Contents" list rather than the "Index," which is where I always want to be. In the Index, you simply type in the beginning of whatever you're looking for ("notesdocum"), hit enter and, poof, you're on the NotesDocument entries. Fast and easy.

But, I'm an impatient guy. I don't want to have to click from Contents (which somebody at Lotus apparently thinks is the better default) to Index (which is what it should be) every time I access the Help.

And, I don't have to.

After all, the Help Database is just another Notes database on your client. That means you can change its design if you want to. So, find it, open it in the Domino Designer, open the "Main" frameset, and change the left frame from "Contents" to "Index." With that simple change you'll find accessing the Designer Help to be a much more satisfying (and quicker) experience.

Do you ever have applications that need to work in multiple environments? You know what I mean: Maybe you have separate Development and Production environments. Or, Development, Test, and Production.

Or, maybe, like us, you're a consultant and have your own internal environment plus the client's Development, Test, and Production environments.

If you have this situation (doesn't pretty much everybody?), you should write your applications to be able to work seamlessly when moved from one environment to the next.

Generally, that's pretty easy to do, but what do you do if you have to do lookups to outside reference databases? If you can be absolutely sure they are always in the same path with the same file name, you can hard-code the lookups, but that always makes me a little queasy.

Alternatively, you could make a keyword document which holds the path or replica id of the database being looked up but, as soon as you do that you've suddenly required double the lookups: one to look up the replica ID and the second to do the lookup to the database.

Not ideal, either.

A approach we often use in situations like this is to put a Computed For Display field on the form and compute out the correct replica ID to use for the lookup database based on the current server. Then, all your lookup formulas simply use the value in the field as the replica ID they're looking up to.

The code is simple and straightforward and saves a lot of time messing around as you move versions of the database from one environment to another:

Teamwork := "85256BD8:0057E563";
ClientDev := "852568CC:00523B4B";
ClientTest := "85256ADC:004B56D5";
ClientProduction := "852569CF:007CBB56";
REM;
Domain := @Domain;
REM;
@If(Domain = "AcmeTest"; ClientDev; Domain = "AcmeQA"; ClientTest; Domain = "Acme"; ClientProduction; Teamwork)

Like I said, simple and straightforward. Remember, though, not to do this with a Computed or Computed When Composed field. If you do, the value will be stored in the documents, which can cause you problems down the road.

OK, I'm late. This was due Thursday and today is Friday. So sue me. Aren't you supposed to save the best things for last? In any case, I'm here and I have a good tip for you, so read on.

If you do web development with Domino, you've probably fought the problem of how to get back to where you came from. What? You don't know what I'm talking about? Sure you do; let me say it more clearly:

You open a database in your browser. You're in the default view. You change to another view more appropriate to whatever it is you're doing. Because you can only see some of the documents in that view at one time, you click Next Page, Next Page, Next Page...a few times to get to where you want to be.

Then you expand one category of the view, then expand another category, then expand again to show the responses to a particular document, which is where you need to do some work. You find the document you want, open it, do whatever it is you were going to do and then save it.

This is where the problem starts.

At the end of the save you find yourself back at the top of the view. More often than not, it's not only back at the top of the view, it's at the top of the default view. If you need to do something to the document right next to the one you just left, well, you have to start the whole darn process all over again.

Switch view. Next Page. Next Page. Next Page. Expand. Expand. Expand. Finally, click, into the document you were right next to a few minutes ago.

It's frustrating. It's maddening. And, worse, it's completely unnecessary. Yeah, that's right: It doesn't have to be that way. Let me explain:

Hopefully, by now you know about Rocky Oliver's new initiative for all of us (YES, you, too) to give a little back, or out, or somewhere, to the general Notes community every Thursday. It's a collaboration tool; let's share.

Great idea, Rock. It was, as we are fond of saying around here, a Blinding Flash of the Obvious. Glad you had the sense to think of it. Wish I had.

So, without further ado, and in the spirit of Rocky's initiative, I'll show you mine if you'll show me yours (figuratively speaking, of course):

I love the formula language. I really do. It's fast, it's powerful, and (shhh, don't tell anybody) it's something a lot of newer developers, those who came at this from a Computer Science or, perish the thought, Visual Basic background, often have a hard time getting their heads around.

And yet, the things you can do with @Formulas are often a little like magic. Or at least, they can seem that way.

The mystery of the disappearing list elements

Let's imagine you have two fields, Company and State. Both are multiple-value fields. Both have several values:

Company	State
Abercrombie	OH
Boeing	WA
Cummins Engine	IN
DaimlerChrysler	MI
Evenflo	OH
Google	CA
Home Depot	GA

Ok, so let's say you need to find all the companies in the list located in particular state. Ohio, let's say. How would you do it? Go ahead. I'll wait. How would you write the code to extract only the names of the companies from Ohio?