Purpose of templates

I have been developing Notes databases for my company for a few years, but I am a 'business developer', not strictly IT.  My company typically installs each production Notes database on two servers and replicates all databases nightly.

I have always made design changes either:
1. during the day on a local replica and replicated the changes to the server when they were finished; or,
2. made design changes directly to the production copy in the evening when nobody is working; or,
3. used a 'test copy' of the database on the server for changes, still a .nsf file, and copied the design elements over to the production copy when they were finished and working

My questions about templates are:
1.What is the practical difference between doing things this way, or using templates to make changes?
2. If I create the database with a .ntf extension and submit a request for it to be put on the server, do database administrators put a .nsf copy of it out on the directory for users? how exactly do I submit changes?
Who is Participating?
Bill-HansonConnect With a Mentor Commented:
Simply put, templates let you keep your design and data separate.

To answer your specific questions:

(1) Using templates allows you to stage design changes to happen automatically during off-hours.  They also allow you to save the design of previous versions for roll-back purposes.

(2) The file extension is irrelevant.  What makes a template is the value of the "Master Template Name" property on the "Design" tab of the database options screen.  For example, the R6 email template has "StdR6Mail" set as the "Master Template Name".  Also, each user's individual email database has "StdR6Mail" set as the "Inherit From Template Name".  This sets up a link between the template and the individual databases.  To update the design of an individual database, you can manually select the database on the workspace and choose "File > Database > Refresh Design..." from the main menu.  You'll be prompted for the server that contains the templates.  Just select the server that contains the template, and click OK.   The "design" task on a Domino server will do the same thing automatically, but only uses the templates found on the current server.  We have the "design" task set to run automatically each morning during off-hours.  That way, when I change the design of a template, our users are not adversely affected.  Strange things can happen if you change the design of a database while people are still using it.

More On Templates

You can use templates is various ways, but the most common use is for a design that gets used for more than one database.  The Email template is a good example of this.  If you want to change the design of everyone's email file at once, you change the template, then run the design task on the server which pushes the design changes from the template to each individual mail file.

You can also use templates to manage your design process.  At our company, for example, we have three environments Development (DEV), Test (TEST), and Production (PROD).  In this model, only templates are stored on the Development server; no data.  The test server(s) contains databases with test records and they inherit their design directly from the templates on the DEV server.  The production server(s) contain live databases, but also contain PROD copies of the DEV templates.

So the TEST and PROD databases both ultimately get their design from the DEV templates, but here's the trick:  The DEV server is in a separate domain than the TEST and PROD servers.  This provides a layer of protection to prevent the DEV design from entering TEST or PROD without human intervention.  The "design" task still runs on the PROD server(s) around midnight, but since the DEV templates are not on the PROD server(s), nothing happens unless you manually refresh the design of a PROD template with the design of a DEV template.

Here's a simple example:

Say we have a database called "Simple Calendar" on our production server that we want to manage using the 3-tier approach described above.

First, you would create a DEV copy (on the DEV server - separate domain) and give it a "Master Template Name"; something like "SimpleCalDev".

Next, you would create a TEST copy (on the TEST server) and give it an "Inherit From Template Name" of "SimpleCalDev".  This tells the TEST copy to get its design from DEV.

Now, create a PROD template on your PROD server(s).  This template is special.  It is the gate-keeper between your DEV template code and the LIVE databases.  For the PROD template, set "Inherit From Template Name" to "SimpleCalDev" and "Master Template Name" to "SimpleCalProd".

The only thing left is to set the "Inherit From Template Name" of any LIVE "Simple Calendar" databases to "SimpleCalProd".

Now here's how it works:

The "design" task will run automatically each night, checking the PROD templates against the LIVE databases to see if the design of the LIVE databases needs to be updated.  Normally, no changes will be detected, and "design" will exit without making any changes to the LIVE databases.

Let's say you've made some design changes and want to test them.  You simply select the TEST database from the workspace and choose "File > Database > Refresh Design..." from the main menu, select your DEV server and click OK.  Done.  Your LIVE databases are still safe because we never updated the design of the PROD templates.

Now, let's say you want to publish the design changes to the LIVE databases.  You simply select the PROD template from the workspace and choose "File > Database > Refresh Design..." from the main menu, select your DEV server and click OK.  Now the design is staged on the production server and the "design" task will automatically update the LIVE databases during off-hours.  Done

I know.  This is a long-winded response, but I think there is a lot of confusion about templates and how they can be used.  This 3-tier approach has worked for me for many years.
jkee54Author Commented:
Templates are basically there for BOTH convenience and control,

The convenience is that you can automatically take ALL your changes and apply them, or all your design and roll it out, without having to copy over bit by bit. There's also the convenience factor when you have multiple databases coming form a single template. The most obvious example is the mail file, where all users are based on the standard mail template. You can easily update all users with a revision at the same time.

The control aspect has to do with making it possible for developers to work away from production, and hand off a well-defined change to an administrator for implementation in production. The version of the template to be applied can now be tracked, if your IT department does such things, and can easily be rolled back to a prior version.

Note that the above is a generalization of the two different types of template Notes provides. The two t ypes overlap, and can work together, but they are really distinct features. The first type consists of any file with an extension of .NTF. These files are automatically "new instance templates," meaning that they show up in the list of templates when you create a new database.

NTFs also automatically set up a default ACL and default set of documents in any new instances created form them, but that does not happen on refresh or replace.

The second form of template is a "design master," where changes to the master can automatically be applied to all descendants (salves) of the master. Any NSF or NTF file can be a design master, by assigning it a master template name in the design tab of database properties. When an NTF is a design master, there is a check box when new databases are created form it, That check box causes the new instance to automatically inherit changes form the template: when the template changes, all instances change. (This requires placement of the master on a server and running the design task on that server; alternatively, you can refresh design of a single database from a master template stored on your own workstation).

Master templates also have some flexibility in having multiple masters for a single active database, or having severfal levels of inheritance.

BE VERY CAREFUL WHEN CUTTING/COPYING DEISGN ELEMENTS FROM A DESIGN MASTER. You will be possibly creating some crazy inheritance rules, which may make later updates fail or behave inconsistently.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.