Access Control List

Hopefully your are not asking yourself what ACL has to do with design? I found that the ACL in databases should be different than templates. The biggest reason is the use of brackets. When a database is created from a template any ACL entry on the template that starts with [ and ends with ] will be copied to the new database without the brackets.

The second is better ACL on templates. As I stated, when I was done development I would make a copy of the database to create the template. I would always select the option to copy the ACL to get the roles and servers so I would not have to re-added them. That means all the extra ACL entries that where needed for testing where also brought along, like a test account.

If development is done in a template the ACL is set when it is created, or when the design requires new roles or access groups to be added. That is the only time that the ACL on a template should be touched. The ACL on your template is part of your documentation. Each entry listed is what the application is anticipating for users. Here is what the would look like:

Documents

Just like the ACL, documents can be added to a new database from a template. The only way this is possible is to have those documents reside in the template when the database is created. These could be configuration documents, lookup or keyword documents, sequential counter document with the starting number set, or even profile documents.

Design Inheritance

After creating a template from the database I would have to set the Template name to the same as it was in production, other wise the server’s design task would not update the application. Yes, this has happened to me more times than I want to admit.

Watch out for creating a new design element in a database that inherits at the database level. Each design element will have prohibit design refresh checked. When creating a new copy the prohibit design refresh will still be set in the new template. Once this flag is set in the template it will be refreshed in the database. This little flag will not surface and haunt you this time, but the next time there is a migration with a change to that design element. The production application design element is set to prohibit design refresh, so it will never be updated. Now don’t go through your production applications and make sure that all design elements do not have this checked, because some design elements this is appropriate like views and agents.

I will be talking about inheritance more in Domino Development Part 2 – Library Templates.

There are two cons to with inheritance when developing in a template: File | Database | Refresh… and web testing. Every time that a design change is made to the template the database needs to be refreshed to test. This is not totally a con because it forced me to do better unit testing in the template first. It is possible to test the template in Notes, but a template can not be opened on the web, so the database has to get refreshed. The pro is having database inherit from the template, just like it is in production (of the little advantages this is the one of the biggest).

Consistency

Every environment is the same, one template and one or more databases using the template. When I designed the migration strategy at the last two companies that I have worked at this has been the easiest for newer developers to understand, because the template is only ever migrated. Since each environment was consistent I was able to follow some naming standards databases and templates.
Templates:
Database Name: <Application Name> Template
Template Name: <Application Name> Template
Databases:
Development: <Application Name> Development
System Test: <Application Name> System
Q/A: <Application Name> QA
Production: <Application Name>

Database Flexibility

When development is done in a template the development database is just a database so it can be over written from Production or any other environment. Once the database is re-created the design can be replaced from the new template. Some configuration changes might be required depending on the application design (this will be a future article as well). This would allow the opportunity to have two or more databases using the same design. The best example of this would be an application database and an archive database. I use two different database to test the ACL because most entries are set to reader.

Summary

Like I said there is no home run reason to use templates when developing, but for me it has eliminated many problems and provide more options. Here are what I see are the pros and cons for using a template in development:
Pros

Cons

Check List Template Development