One of the main tasks I do as a Senior Notes/Domino consultant is fix/enhance existing applications. While I've been using templates since I started developing in Notes back in 1996, over the past several years the approach I've taken is to create a new template for each set of design changes under development.

If I've never touched the database before, and there is no existing template for the database, I make a copy of the production design as a baseline template. I give this baseline template a name of Service Requests Template (1.0) and a filename of serreqs-1_0.ntf. I change the production database properties so that it inherits from this template.

If I have worked on the database before, but its been a while and I can't verify if anyone has changed the design since I last changed it, I create the next template in the sequence using a copy of the current production db's design.

Then, I make a copy of the baseline or current template and increase the numbers: Service Requests Template (1.1) and a filename of serreqs-1_1.ntf. Finally, I create a copy of the production database to be used as the development environment, and change its properties to inherit from this new template.

This approach has several advantages:

1. I can test my design changes in a development database that inherits its design from the new template while the production database inherits its design from the current template. Sure, you can accomplish this without using templates, but unless you're making your changes to the live production database (a big no-no), you'll have to designate your dev db as a template and use it to refresh the design of the prod db. But if you do that and something goes wrong, how will you restore the prod db to its original design? If the problem is urgent, who has time to wait for the db to be restored from a backup tape? And what if a good backup doesn't exist?
2. I can make changes to a local replica of the template, instead of a local copy of the production database. This is very useful if the production database is several hundred mg, and I don't want to waste time making a local replica.
3. When it comes time to move the changes into production, all I need to do is change the design template name of the production database and let the Designer task make the changes for me overnight.
4. Opening a template with no documents is much faster than opening a local or server based replica of the actual production database.
5. Comparing design changes between templates using a product like TeamStudio Delta is a snap.

For an excellent discussion of using Notes design templates effectively, please see Darren Qualls article on the e-pro website.

I'll never forget the time when a customer told me that a view I had changed according to his requirements wasn't working. Since I had a copy of the design I last pushed into production, I was able to use Delta and determine how the view had been changed since I last put it into production. It turned out that the customer had changed the view himself, but "didn't remember" making a change. Instead of pulling an "I told you so", I asked if the customer wanted the view restored to the way it was originally implemented. Of course he did.

No comments.