Beyond The Yellow Bubble

One of the many classes in the .Domino Framework is the DominoMemo class.  The class is designed as a helper class for applications that have a need to compose and send e-mail.  A primary reason for trhe class is to remove the need to know and understand all the special fields used by Notes memos.  This code is contained in the base.Domino.MailServices and Domino.MailServices LS libraries.  The next release of the .Domino Framework will contain a number of enhancements to this class based upon requirements I have had for a number of recent projects.

Properties:-
Body : NotesRichTextItem - I have added a this public property to allow direct manipulation of the content of the body of the memo - e.g. to add a tab
ExpiryDate : NotesDateTime - Allows direct access to set/read the expiry date for the memo
Principal : Text - Provides a way to change the name of the sender when the memo appear in the in-box for Notes and some Internet mail clients
Logo : Text - Controls which logo is displayed at the top of the memo
ReplyTo : Text() - Sets the e-mail address used when the recipients uses reply
Sender : Text - Changes the identification of the sender of the memo.  This changes the From, Principal,  and DisplaySent fields that can be used by different mail clients to display who sent the memo.
Sign : Text - Used to control if the memo should be signed before it is sent (Note: Notes has an anoying habbit of signing memos by default in some cases)

Methods:-
Initialize() - Initializes the memo by setting the value of Form to "Memo"
Notify(testSend : Boolean) - This is an existing method that sends the memo to the intended recipients.  The method tests if the database is a production database.  If it is not, the recipients are changed to be just the current user and a message appended to the bottom of the memo with details about the intended recipients if the database had been in production.  This method is used to prevent worklflow applications from sending messages from the Dev//QA environment to anyone other than the tester.  The method has been enhanced to deal with issues of positioning text that can occur when the body of the memo has been copied from another document (e.g. to include attachments without the need to extract).
RenderDocument(Source : NotesDocument) - Appends an image of the nominated document into the body of the memo

Part of the art of customizing the mail template is doing it in such a way that the maintenance effort is as little as possible each and every time IBM release a new version of the mail template.  The following is one suggestion for reducing the footprint of your customizations.

 

1) Add a "Custom" subform to the Memo & Response forms (either one each or one common subform)

2) Add any number hidden fields to the subform needed to add additional internal data to mail documents

3) Add any number of actions that you would like to appear.  Granted you do not full control over where these actions appear compared with modifying the forms themselves, but I can live with this compromise to reduce the impact of the changes.

 

4) Procedural Programmers:

4.1) Add code to each action to define what each action should do

4.2) Add code to the QueryOpen, PostOpen etc events of the subform as a way of customizing what happens when the form is processed.

 

5) Object Oriented Programmers:

5.1) Create two new classes one for the foreground document and one for the background document

 

e.g.

    Class DominoUIMemo

        Private iNotesUIDocument As NotesUIDocument

        ....

    Class DominoMemo As NotesDocument

        Private iNotesDocument As NotesDocument

        ....

5.2) Wire the QueryOpen event to instantiate the above classes

5.3) Modify the UI class to trap any form events as part of the constructor. 

 

e.g.

 

Sub New(Source As NotesUIDocument)

On Event PostOpen From Source Call OnPostOpen

On Event PostSave From Source Call OnPostSave

End

 

5.4) Add methods/properties to either class to support the custom Actions

 

The above will not handle all the likely mail customizations needed but it is a good start and each time a new mail template is released there is a single change needed to the existing IBM code - adding the "custom" subform.

 

Note: Adding subforms does have a performance impact, but given the number of subforms already included in the standard mail forms and the amount of processing that takes place it is unlikely to be noticeable.

A current project I have is to address an anomaly in the way the mail system works for reminders and alarms.  When a reminder is created and an alarm is set the current subject of the reminder is copied from the Subject field into a $AlarmDescription field.  If the subject of the reminder is ever changed from that point on the contents of the $AlarmDescription is not being updated (At least not with the 7.0 mail template)...

---

To solve this I am extending the .Domino Framework into the domain of the Mail database.  A scary thought!  So far I have created a DominoMailDB class to represent the mail database.  This has a SyncAlarmSubjects method to scan though all alarms and fix all the documents where the $AlarmDescription does not match the Subject field.  Whilst I am there I have fleshed out a DominoMailDocument class to represent the majority of documents in the Mail database.  This class is extended by a DominoMessageDocument class to cover memos and reminders and a DominoEvent class to cover appointments, meeting, and reminders.  A DominoReminder class extends the DominoEvent class providing access to reminder information such as the Alarm Description field ($AlarmDescription).

 

Having worked on a few projects requiring customization of the mail template I am thinking the above approach may be a lot cleaner and leave a smaller footprint on the mail template.  In theory most of the changes to the business logic of the mail database can be included in a single Script library.  The only other customization that should be required is to the presentation layer to add fields actions etc.  Which, as we all know, we should ony do when absolutely necessary because each new release of the mail template creates a huge headache for somebody to integrate!!!

 

All going well this and other mail-related functionaility will be included in the next beta release for the .Domino Framework.