Ben Poole

OK, so here’s something a little controversial. We all like to read articles about best practice, doing things the “correct” way, and so on. How about some stuff on the bad ideas, the so-called anti-patterns that exist? Or is that an overly-negative endeavour do you think? I dunno. But I’m going to kick this off anyway, with some gems from the Notes world… Feel free to chip in!

First off, a view, with an action bar button in it. This button is labelled “Create blah blah document…”, and naturally enough one would expect that it performs some kind of @Command([Compose]) call. Not so! Check this out:

    @Prompt([OK]; "New Document";
    "Please use the button on the main navigator to create a new blah blah document");
    @PostedCommand([FileCloseWindow])

Urgh. Almost as bad as the Querysave form traps that prevent the use of CTRL-S or similar, in favour of pressing an action bar button.

OK, next. Querypaste events in every single view of a database, denying document pastes. Plus, just for good measure, an agent that removes any documents pasted-in. Now, there may be a good reason for this in the odd application, but in every single database you ever created? Sorry, no.

Next! This guy was just kidding himself:

    TheEnd:
        Msgbox "Process completed. Error count was 0"

OK. So what’s this next bit for then?

    lblErrs:
        intErrCount = intErrCount + 1
        Resume TheEnd

Gah. On to the last one for today (these are all real examples, and better still, all feature in the same application).

An agent designed to export a 60+ column view. This is done by concatenating a load of strings to make up the “header” of the export text file. These strings all correspond to the view column titles, and are delimited by a tilde. Cue one entirely senseless bit of code already — NotesView.Columns() anyone?

Then, the code walks the view, and for each NotesDocument, extracts a value from the ColumnValues property and appends it to this gigantic string. Meh. Here’s an extract:

    data1$ = Doc.Columnvalues(2) + "~"
    data2$ = data1$ + Doc.Columnvalues(3) + "~"
    data3$ = data2$ + Doc.Columnvalues(4) + "~"
    …
    data68$ = data67$ + Doc.Columnvalues(69) + "~"

What do you reckon on that? The export takes over an hour in this database (there are around 15,000 documents in the view), and the end-result still has to be manually imported into one’s reporting package of choice (MS Excel). How would you go about addressing this? For a start, why not use COM? Go straight to Excel. The Lotusscript agent isn’t readily portable, and does not lend itself to tweaks. It skims NotesDocument objects instead of using the far more efficient NotesViewEntry class. The string concatenation is an abomination, the resulting export file is horrible, and the code itself, when printed, takes up four sheets of A4. It also crashes my Notes client spectacularly nine times out of ten. First time I’ve seen a RBOD in Notes 6.5! Oh yes, the database contains at least three implementations of this anti-pattern, each fundamentally the same, just tailored for their respective views. Code re-use anyone?!?

Bring on your tales…

Filed underbad practice, lotus notes domino, antipatterns