50. 替换设计和刷新设计——Lotus Notes的程序部署和更新之理论一文介绍了理论上LotusNotes的程序部署和更新之概念和过程，实践当然相比更繁杂，涉及到的境况和物事更多，需要更多考量。本文就介绍和讨论一下这些问题。
除非微不足道，任何程序开发都会遇上代码重用的议题。Lotus Notes的程序开发是以一个数据库为部署单位的，重用代码也就是用一个数据库继承另一个称为模版的数据库的设计的形式，应用数据库在创建时复制单个模版数据库的所有设计元素，或者在开发过程中引入（可能多个）模版数据库的特定元素（自R 8起，Lotus Notes改用应用程序的术语代替数据库，不过在笔者的系列文章里，这两个词语时常混用）。一个应用中，既有继承自模版的设计元素，又有专属当前应用的新元素。当模版里的设计元素发生变更后，要保证继承它设计的数据库的相应元素更新，就必须对它们刷新设计。这样自然就产生了区分一个应用中继承的和其他的两类设计元素的问题。对此，Lotus Notes有两种应对方法。第一种方法是应用数据库继承某个模版数据库的设计（在数据库的属性信息框的设计页显示和设置），那些不属于模版数据库的新设计元素就必须特别标记“禁止设计刷新和替换”。也就是普通元素都来自模版，没有标记。第二种方法则是应用数据库本身不继承任何模版，特定的设计元素取自某些模版，在它们的属性信息框的设计页标注模版的名称。所以标记的情况正好和第一种方法相反，没有标记的普通设计元素都是专属于当前应用。两种方法也可以混合使用，即数据库继承一个模版，其中的某些元素又来自其他模版。这样，数据库中的设计元素就有三种，没有标记的来自数据库继承的模版，单独标记模版名称的来自该模版，标记了禁止设计刷新和替换的则是特有的设计元素。这两种方法各适用于不同的场景。如果一个模版实现了完整的功能，比如一个文档数据库或者邮箱，继承它的应用只需做少量调整和定制，那第一种方法比较方便。如果模版只提供一些基础性的功能，而且一个应用须用到多个模版的设计元素，则适合采用第二种方法。不那么典型的情况下，可以任选一种或者混用。
以上讨论只是针对开发人员能在其中直接修改数据库设计元素的本地或者开发服务器环境。企业的正式服务器上的数据库通常不允许直接修改，而是由管理员按照一定流程维护，修改程序必须通过设计刷新或替换。因此这些生产环境下的数据库中的任何设计元素都不能设置“禁止设计刷新和替换”的属性，也就是说，所有数据库的设计元素都须在设计刷新或替换时从一个或多个模版继承，实践中方便和普遍的做法是用设计替换完全从一个模版更新程序。这是因为开发环境下的对应数据库虽然可能继承自多个模版，但是开发人员提供给管理员的模版必然包含了所有的设计元素，所以在正式数据库更新时，只需从一个模版获取设计元素。如果采用设计刷新，管理员就必须确认正式数据库继承的模版名称和开发人员提供的模版名称一致，并且刷新选择的模版服务器上没有其他同名的模版，这样做既繁琐又容易出错，所以采用设计替换直接选择要继承的模版文件，简单又可靠。
在R8以前，在Domino Designer里打开某个数据库中继承的设计元素时，Designer会提示所做的修改在将来的设计刷新或替换时会丢失。虽然这样的提醒不能说完全没有用处，但每次都出现也很扰人，特别是对于熟知这一点不会犯错的熟手。
于是从R8.5起，IBM决定把这项提醒改成可配置的，用户可以选择下次不再出现。也可以在Designer在选项里修改这项配置。
但是令人沮丧的是，一个bug产生了。这个可配置的提醒是新的以Eclipse为基础的Java开发环境的功能，IBM忘记去掉原有的本机代码的Designer的提示。这样当编辑脚本库、代理等使用Eclipse类型编辑器的时候，只会看到一次可取消的提醒；编辑表单、视图使用传统本机代码的编辑器时，会看到两次提醒，第一次是Eclipse的可配置取消的，第二次的则和原来一样，始终出现。而且直到最新的R9，这个bug依然在。