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...