PreviousNext…

Best practice (Part 3: workflow & stored forms)

Introduction

Blimey. 'Architecting.' That sounds suspiciously American. Do you mean 'designing'?

Well, yeah, sorry. Let's — ahem — move on. Part 1 of this series talked about giving your application a bit of forethought in terms of where best to put your code. Now we move on to some practical assistance in this regard for you, the fledgeling Notes developer (or indeed for the fully-fledged hoary old coder, who cares?)

If you're a bit of a Notes geek, the whole area of mailflow can get quite interesting… One of my biggest bugbears is that because Notes is a collaborative platform based around messaging, people feel obliged to have their application mail someone about something. Grrr… Come on, we've all done it. OK, so lesson #1: don't mail people for the sake of it. Think about what you're trying to achieve with an application, and take the business processes from there.

Moving on, have you ever produced an application that chugs documents round to various people via Notes mail? Using stored forms? Heh. Aren't stored forms a nightmare?!? They're a great idea, and they have their place. But with a bit of ingenuity you can avoid them sometimes, and do so in a way that doesn't detract from usability. This is going to be the focus of this article.

You probably have used stored forms. They allow you to send mails with nice header graphics and formatted text / tables / whatever in them, not to mention all those extra fields and controls. Well, that's cool. It helps users, and makes life easier. How about I make life harder for you, and we move on to something slightly more sophisticated with the same end result? Yeah? Good. Consider this:

  • You have a view, with documents in it. These documents are created by database "super users" and contain the text / otherwise for your emails.
  • You have a button or whatever that allows you to select documents (you can of course literally mean "you", or indeed the server, selecting documents programmatically. I'm not fussy) and mail people mentioned within those self-same documents. So, you mail them one or more of your "template" emails.

Now, at this point, most developers would simply do some kind of @MailSend (or if they're more flash, NotesDocument.Send(True)) with a stored form. Far too lazy, and not nearly as much fun. Consider generating a standard email (i.e. Notes "Memo" form) on the fly, complete with rich text elements, dynamic elements per the underlying document, formatting, and so on. It will take you longer in terms of coding / tweaking, but it makes a hell of a difference in terms of source and target mail size, and also allows for easier updating of form design (ever tried to extract the original form from a stored form?)

As an example, I recently got a stored form that was 137KB in size. This document was designed to tell me about a database on one of our servers, providing a button to take a local replica of said file. As a challenge, I knocked up a new version of this document that was identical in terms of look 'n' feel and functionality, yet didn't use a stored form. It took me about an hour to code, and was just over 18KB when emailed. In a reasonable size organisation the dividend here is quite clear, even in this age of vast disk arrays and so forth (who uses shared mail?!?). Not to mention the fact that with lots of stored forms whizzing around, UNK** tables can fill up, and mail routers fail to deliver (ever seen that 'orrible error message, "Database has too many unique field names" or its bed-fellow "Cannot Store Document; Database has too many unique field names…"? That's the UNK table freaking out on you, though it doesn't happen nearly as much in R5 and up).

Anyway, forgetting all that infrastructure stuff, surely as a Notes programmer par excellence you take pride in developing such clean efficient solutions? ;-)

The attachment

The attached database contains an "About…" document, a couple of views, an agent and a couple of forms. A button in the "Main view" will send a selected Notes document, as a dynamically generated Notes mail, to you. It's not a stored form. Grab the agent code, and do with it what you will. Add dynamic / rich text elements to your mailshot templates, and observe the difference in size of sending such documents with and without their forms attached. You can even send mails with dynamic buttons (even though there's no nice and easy NotesButton class to leverage) in them, if you think about it hard enough (I did this with my 137KB - > 18KB mock-up mentioned above).

I must use stored forms!

The flip-side of all this is the application that absolutely has to use stored forms. OK, fine. But if these documents end up getting sent back to a database, I can help here too. Again, with reference to the attached database, you should discover in there a resource document containing a code snippet devoted to stripping down stored forms. What this actually does is commented in the code, but essentially, it strips out all "stored form fields", preserves the application-specific fields you need, and gives the document a form attribute. This means that what was a stored form document can now happily reside in your application as a normal Notes document: fields are referenced from a common field table, there are no UNK-related issues, etc. You could perhaps use this code in either a scheduled agent, or in an agent triggered when new mail arrives. Either way, as a developer you get back the flexibility / tweak-ability that is lost when a document stores its form, and database size and speed benefits also.

** - if you want to know more about UNK, look it up in the Lotus Notes knowledgebase… or ask me (contact details to your left). If enough people ask, I'll do some kind of fiendishly techie article on UNK tables and how to look after 'em.

Further reading

Downloads

Comments

  1. I wanted to personally thank you for all the posts related to the Best Practices.
    these were all absolute fantastic articles.
    I myself has got a lot of inner sites reading them.
    Thanks once again.
    TamajitTamajit Sarkar#
  2. Thanks, always good to get some feedback! Let me know if there are other areas you'd like me to look at.Ben Poole#
  3. I was looking at the code in the agent and was interested in the memory management line "Set docNewMail = Nothing…" I don't "recycle" anything when writing in Lotusscript, I thought it did it's own garbage collection. Should I be recycling all Notes Objects on loops\ iterations etc.?

    Anyway, learn something new every time I visit the site. Good work fella!Nick#
  4. Nick -

    Nah, I'm just a tart. ;-)

    LS manages memory pretty well by itself as you rightly point out. I do tend to recycle some objects though, especially when I'm dealing with code that loops through, and sends, NotesDocument objects. I find that things can sometimes get messy, especially as the collections being looped increase in size. Recycling seems to help, and also assists with debugging: it has been known, believe it or not, for me to make some dumb-arse mistake that means variables and items from one mail document are carried over into a new one in my loop. Recycling obviously puts that nonsense to rest.

    As with all these things though, your mileage may vary. Mabye I should look into this stuff a bit more…

    Anyway, thanks for the kind words, and keep tuning in!

    PS Thomas Gumz has expanded on this a little today, over at the LDD:

    linkBen Poole#

Comments on this post are now closed.

About

I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.

";
File Attachment Icon
bp_part3.zip