Domino Environment Part II: Library Templates
With an understanding of why templates should be used for database development from Domino Development Part 1 - Environments . Lets take a look at what other benefits there are to developing in templates. I use two different types of templates: library & design. Both of these templates never migrate from the development environment. The library will be for reusable code, and the design will be used with third party applications. I will save the design template for Part III.
Rule #1: Never use Prohibit design refresh in a template (See Domino Development Part 1 - Environments).
Rule #2: Use Design inheritance to maximize code reuse.
Rule #3: Database inheritance should only occur with databases, except for third party package enhancements. (Part III)
Prohibit design refresh
The only place that I have found value with this setting is in databases. The best example is your mail database each folder you created has prohibit design refresh set otherwise the folder would be deleted at night when the design task runs on the server. This same setting can be used in applications for views, agents or any other design elements. Prohibit design refresh can actually be a hindrance even in a database, because the design never can be updated. Lotus realized this during upgrades of mail databases, so they added a new formula option to update a folder based on a different view. Check out the 'Upgrade Folder Design' agent in the Mail 6 template, or 'Upgrade this folder or view to R5 design' in the Mail 5 template.
Any time a new design element is created with the 'Inherit from Master Template' set, the prohibit design refresh will automatically be checked. So if a new agent, form or view was created in your mail database it would have the prohibit design refresh enabled. This prevents it from getting deleted when the design task runs.
Design element inheritance
Inheritance in Domino follows the same concepts as OO. In LotusScript (which has OO characteristics) classes can inherit from another class which is like database inheritance. Design element inheritance resembles the method or property of a class, because they can be overridden or defined differently in each class. Following the same concept of other OO based languages lets start building a framework or library for the Notes/Domino environment. The library will reside in a template, there could be multiple templates (Notes, Domino, web, admin, mobile). Don't get to detail with the library templates they will be hard to maintain. These library templates will hold reusable design elements like subform footers, script libraries, an all documents view, or a hybrid of design elements.
Reusable Footer Example
The footer contains the date and time of when someone created and last updated a document. This subform should always inherit so fixes and new features can easily be implemented. Let's assume the subform is in the 'Domino Library Template' with the 'Master template' property set to 'Domino Library Template'.
Implementation
- Open the 'Domino Library Template'
- Select the subform 'User Info Footer'
- Select Edit-Copy from the menu bar
- Open the destination template
- Select Edit-Paste from the menu bar.
- Select 'Yes' when prompted to inherit future changes
That is 6 more steps than I want to do and this is simple. When there are multiple design elements that are needed the task can become tedious and error prone. Each design elements need to be selected based on the design type and then repeat steps 3-6 for each. To easy the pain copy and pasting the design elements I created a tool to accomplish this. Quick Elementer will group multiple design elements and allow the implementation of the design elements in a click or two. It is very much like the group objects in Teamstudio's Design Manager (formally Teamstudio Librarian). It will also set the inherit from Master Template property automatically.
Hopefully Part II will not take me three months to write. Don't forget to check out Quick Elementer
Quick Elementer
Updated version of Quick Elementer is now available.
Quick Elementer is a document based design element implementer. It is very much like the group objects in Teamstudio's Design Manager (formally Teamstudio Librarian). Elementer will perform the task of coping and pasting design elements form one database to another. I created this because I am a big believer in code reuse using templates and got tired of copying and pasting!
Some of my modules (groups of design elements that work together to perform a function) required more than just a script library or a view. Some required 2 script libraries, 3 views, a form and an agent. With my forgetfulness I would spend wasted time trying to figure out why my module would not work that wored in other applications.
The Quick Elementer form
A Quick Elementer allows the selecting of multiple design elements based on what is in the database. The inherit design field will set the design element's 'Master Template' field to the master template name of the current database. You can sort the design elements base on the type of design or the design element name. The 'Copy Elementer to Database' will prompt for a destination database and copy the design elements.
The Quick Elementer view
The view lists the design elements that are apart of the module and if the future design changes will be inherited. The 'Copy Elementer to Database' will prompt for a destination database and copy the design elements.
Copy Elementer to Database
When all the design elements have been copied to the destination database Elementer will ask if the destination database should be opened.
