MMM: Using the Mail-Merge Method

02/20/2008 01:41 PM by Chris Toohey

I've been doing this for a while - just never really put a name to it. And since Rob points out that I'm coining my own terms , I thought I'd put this out there...

The Mail-Merge Method, or MMM, is something that can pretty much be applied to anything - from notifications, UI document rendering, dynamic content, and countless other uses. In fact, I'm actively using this method in Project: Yellowcake to generate dynamic content markup on-the-fly... but that's a story for another post!

MMM basically consists of the following:

Author's Note: My first thought was to just now write "Step 1:", which was immediately followed by "Cut a hole in the box..." ;-)

1. Create unique-to-the-engine keywords.
2. Create a delimiter string that won't normally be used in your content, which you'll use as a wrapper for your keywords. For example, I tend to use <<keyword>>, but you may want to get more unique than that: %^&keyword%^&.
3. Create a simple merge-point for your expected content.

If I lost you on that last step, that's ok -- it requires a much deeper explanation than a single bullet-point...

To illustrate how effective MMM can be (as well as help define the method), let's say that you want to create notification email-functionality in your given workflow-based application. Most people would either write an email on-the-fly via @Formula (<shudder>) or get really tricky and write a simple-and-static email generating Lotuscript-based Agent Design Element called "notifications". "notifications" runs either on-event or on-schedule, but basically grabs a document and generates an email to a given recipient with a doclink and some information on the given document.

Simple right? Add a field. Now change the font-weight for a given item in the body. Now put a red-colored, 8pt font-size disclaimer footer at the bottom of the email that says "This is an automated response, please do not response and think the sender actually cares...".

You'll spend more time playing around with the formatting of the email message than you will with the workflow of the application itself. Trust me - I used to do that.

And before you ask "Why should I care what the email looks like?", consider this: it's arguably part of your job to show just how flexible and helping the given technology investment can be - and giving someone pretty email notifications can be a very simple and effective way of showcasing the capabilities of the technology... but I digress.

So you've got this notification, but you have to maintain an arm-length codestream for formatting, etc.

Now imagine this instead:

I take a simple Form Design Element, which I've called template_email, to create various "email templates" which my notifications Agent simply grabs en-masse and replaces <<keyword>> with the keyword's correlating NotesItem in the given document.

This allows me to create a simple Super User-Defined Notifications Engine in my various applications... which not only provides the application administrator the ability to create and maintain their own notifications, but it also keeps me out of the Domino Designer client playing around with RTItem formatting. The user community benefits from my laziness!

And this is only an example of MMM. In Project: Yellowcake, I'm using the MMM approach to get some pretty amazing functionality... but like I said, that's for a later post.

I'll work on getting both more examples of this method as well as my Notifications Engine out ASAP - provided there's an interest in such a utility. ;-)