Beyond The Yellow Bubble

So this week I spent a lot of time trying to think of cool ways to make the .Domino Framework more easily customizable.  This following is the solution I have come up with and can apply to any template that uses OOP and want to make the code easily customized....

The .Domino Framework contains a LOT of classes.    Using one example, the Domino.Applications namespace contains classes for DomioSession, DominoDatabase, DominoDocument .... that extend the NotesSession, NotesDatabase, and NotesDocument ... classes.  I have added a lot of methods and properties that I have found to be useful, including a lot of ideas that came from other Notes developers.  But this is certainly not a complete list and other people may even want to change the definitions of some of the properties, methods, and events to improve or adapt the code for specific needs.

1. I have copied all "My" code in a new LotusScript library called Base.Domino.Applications
2. I have renamed all the classes to start with base.  e.g. baseDominoSession, baseDominoDatabase, baseDominoDocument
3. Returning to the original Domino.Applications library, I have included Use "Base.Domino.Applications"
4. I have then rewritten the class definitions to extend the base classes.  e.g. Class DominoSession as baseDominoSession
5. And finally I have removed all the code from these class definitions except for an empty constructor.
6. All the code in the .Dominio Framework continues to use the DominoSession, Dominodatabase, DominoDocument... classes as before so any customization added to the "Domino" classes will always become available.
   

Anyone adopting the .Domino Framework is now able to customize the classes with their own code without the need to modify any of the base code.  Customization can include adding new properties/methods/events as well as rewriting/overloading the existing properties/methods/events. 

The one thing a customizer needs to do is make sure that the Prohibit design refresh flag is set for the Domino.Applications library (I can probably set this as the default).  That way when a new version of the .Domino Framework is released it will update the Base.Domino.Applications library (and hence the base classes) without making any changes to the existing customization.

This technique could be applied to any template/code library.  Imagine if IBM were to apply this technique to their own templates such as the mail template.  We could customize the various classes developed by IBM without having to worry about how to merge the code again when a new release becomes available.  I could modify one of their methods in my ownh library and then their code would run my code...

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.