Beyond The Yellow Bubble

I started work today on building out the documentation for External Dependencies. 

External Dependencies are used within the .Domino framework as a way of documentin g links to external applications via meta-data.  This brings a number of advantags to the application.

1. Documentation of external dependencies allows an analyst/developer to make a quick assessment of the extent to which an application is linked to others. This is an important part of application documentation that is often forgotten or left outdated.
2. Storing the details of dependencies in the form of meta-data allows changes to be made to the location of external dependencies without the need for programming changes.
3. Storing the details of dependencies in the form of meta-data allows a change to be effected with a single change.
4. Storing the details of dependencies in the form of meta-data makes it possible for development, QA, and production instances of an application to maintain links to different external sources.

One of the technques I developed for working with external dependencies was to create a Static Property for the database to avoid the need for locating the database each and every time.  The first time Application A has need to refer to Application B it searches for an external dependency document that defines the location of the database and then opens the database.  On subsequent attempts it refers to the chached copy of the database object.

Example:

'/**
' * Provide static link to Subpoena database
' */
Static Property Get FACTSubpoenaDatabase As FACTSubpoenaDatabase
  Static This As FACTSubpoenaDatabase ' Static reference to Subpoena database
  Dim ExternalDependency As DominoExternalDependency ' External dependency defining location of Subpoena database
  Dim SubpoenaDB As NotesDatabase ' Subpoena Database

  If This Is Nothing Then
    Set ExternalDependency = New DominoExternalDependency(EXTERNAL_DEP_SUBPOENA_DATABASE)
    If Not ExternalDependency.Document Is Nothing Then Set SubpoenaDB = ExternalDependency.GetDB
    If SubpoenaDB Is Nothing Then Set SubpoenaDB = Session.CurrentDatabase
    Set This = New FACTSubpoenaDatabase(SubpoenaDB,"" )
  End If
  Set FACTSubpoenaDatabase = This

End Property

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.

An application I am working on has the need to change view selection formuale from time to time and we wanted to avoid the need to deploy a new version of the application each and every time such a change was needed due to the high cost of the change control/release process (man I love SDLCs....)

Given the NotesView class has a read/write SelectionFormula property I have been able to develop an extension Domino.Reflection namespace to coordinate the activities associated with modifying the view selection formulae at run time.  A special Admin form is provided in the application which allows an administrator/developer to select a view and then change the view selection formulae directly.  I have developed a demo of this functionality that will be included in the .Domino Framework database when it is posted on the OpenNTF Web site.

After giving this a lot of thought I have finally decided to create a new project on OpenNTF for the .Domino framework.

The .Domino Framework provides Lotus Notes developers with an Object oriented architecture for rapidly developing extensible applications. The framework attempts to provide a practical balance between good software design and Rapid Application Development (RAD). Because the LotusScript scripting language is very similar to Visual Basic, the framework seeks to take many of the good ideas developed for the VB.Net framework developed my Microsoft. These have been adapted into a Lotus Notes context.