在IBM Lotus Notes和Domino中编写快速查找代码
Published by admin on 09月 24, 2010
阅读在 IBM Lotus Notes 和 Domino 中编写快速查找代码的 11 个技巧。作者考察了 Lotus Notes 和 Domino 中的 @DbLookup @Formula 并描述了一些新技巧，供开发人员在编写新应用程序或对现有应用程序进行性能问题的故障检修时使用。
本文将考察 @DbLookup，它可能是 IBM Lotus Notes 和 Domino 中最流行的 @Formula。现在的 Lotus Notes/Domino 应用程序开发人员可能无法想像在不使用此公式的情况下创建应用程序，而超过 15 年的性能测试和客户故障检修已经表明：在应用程序的一个表单中，常常会以多种形式使用此公式数十次。
但是同样的经验表明：性能问题往往也与这些 @DbLookup 公式有关。我们已经看到，复杂的企业应用程序由于使用了这些公式，从而导致了无法接受的低性能而陷入实际的停顿。
本文将描述 11 个技巧，使用这些技巧能保证加快几乎任何应用程序的运行速度。这些技巧的范围广泛，包括从简单的一行代码到 @DbLookup 公式处理方法的根本性改变，但是所有这些技巧都已久经考验。
本文假设您具有 Lotus Notes/Domino 开发的一些知识，因此诸如 @DbLookup 公式的一些基本参数等内容，将不再赘述。
本文将使用各种示例说明每个技巧的价值。为简单起见，我们使用一个 Help Desk 应用程序，它包含一个 Contact 表单和一个 Ticket 表单。此应用程序的基本工作流程是：客户调用，创建 Ticket 文档，接下来，获得客户的公司和名称信息后从下拉列表中选择适当的公司名称和联系人名称。还要选择适当的调用类别（例如 Product Help、Sales 等等）。下面给出一些例子，在这几种情况下使用 @DbLookup 公式会将非常有用：
- 从一个包含所有公司的列表中选择公司名称
- 从一个包含该公司所有联系人的列表中选择客户名称
- 从一个预先确定的或动态的问题类别列表中选择问题类别
捕获错误
我们都不希望进行错误捕获，但是事与愿违。在 @DbLookup 公式中（本文中 @DbLookup 既指 @DbLookup 又指 @DbColumn 公式），错误往往更加难以处理，因为公式常常不仅取决于用户输入的键，还取决于其返回的数据。就是说公式可能在某一天能够工作，而在另一天就不能用了 —— 对开发人员来说这一直是个难题。
例如，假设公司名称在不同的 Contact 文档中有三四种不同的写法（比如 LSDevelopment Corporation 和 LS Development Corporation）。如果接下来要查找该公司的所有联系人名称，但是键入了 “LSDevelopment Company”（比方说），则找不到任何匹配的名称。
有多种方法可用于更精确的输入键（比如下拉列表），但是为了便于讨论，假设即使使用严格的开发技术，@DbLookup 也返回了一个错误。
错误检查的基本方法是编写如清单 1 所示的代码：
清单 1. 错误检查
v := @DbLookup(“Notes”; “”; “(Lookup-ContactsByCompany)”; CompanyName; “ContactName”);@If(@IsError(v); “The program cannot find any contacts for this company”; v)
这段代码用于执行查找并检查错误条件。如果存在错误，则返回一个文本字符串，告诉用户存在一个问题；否则，则返回查找得到的值。
这虽然与性能无关，但却是很多应用程序都存在的一个基本问题，因此不能忽略。可将其看作一个附加的技巧。
使查找频率最小化
考虑下面的查找公式代码：
@If(@IsError(@DbColumn(“Notes”; “”; “(Lookup-Companies)”; 1); “There are no
company names”; @DbColumn(“Notes”; “”; “(Lookup-Companies)”; 1))
这是一个很常见的错误，因为查找执行了两次，从性能角度来说这就是个问题。您可能认为第一个查找很好地缓存了查找结果，因此第二个查找就不会执行，但事实 并非如此。第二个查找比第一个执行得快，因为后者（确实）缓存了查找结果，而前者原样执行。因为没有功能上的原因要求像那样编写公式代码，所以您应编写如 下代码作为替代：
v := @DbColumn(“Notes”; “”; “(Lookup-Companies)”; 1);
@If(@IsError(v); “There are no company names”; v)
另一种导致执行不必要的查找的错误是：比如，一个 computed 字段在以下情形时计算查找公式：
- 第一次创建文档
- 按下各种按钮以编辑模式刷新文档
- 保存文档
- 在稍后的日期以读模式打开文档
- 在稍后的日期以编辑模式打开文档
- 在稍后的日期保存文档
最常见的是：希望只在第一次创建查找时执行查找。在这种情况下，将字段设置为 Computed When Composed 以防止再次计算。
在其他情况下，您可能希望每次以编辑模式打开文档时都执行查找。此时，按如下内容重写公式：
@If(@IsDocBeingEdited; “”; @Return(FieldName));
v := @DbColumn(“Notes”; “”; “(Lookup-Companies)”; 1);
@If(@IsError(v); “There are no company names”; v)
在这种情况下，FieldName 是此公式所在字段的名称。如果不是以编辑模式加载文档，则公式将只是保持该值并停止执行（参见图 1）。否则，将像以前一样执行 @DbColumn。
图 1. 关键字公式
正确地使用缓存
另一个常见错误是误解了 NoCache 参数的用法。通常，错误的推理是：认为数据越重要就越应该使用 NoCache。事实上，正确的思路应该是：执行查找的频率与数据变化的频率有关。
例如，如果要查找的数据的变化频率很低，比如，一个月变化一次，则很难想象查找公式中需要使用 NoCache。在示例中我们假设创建了一些供 Ticket 文档引用的类别。该列表可能由应用程序的所有者维护，每隔数月（也许是发布新产品或输入新公司时）才执行一次更新。
另一方面，假设 Ticket 文档查找发出调用的客户名称。如果此客户一小时内发出两次调用，则我们会因为在第二个 ticket 上的查找中得不到客户名称而非常不方便，这是由于名称列表被缓存在了前一个查找中。在此类应用程序中，我们常常会看见 Help Desk 职员整天开着数据库，因此当天将缓存的查找长时间缓存起来比较方便。
避开下拉列表陷阱
多年以来，表单中出现的所有严重的性能问题中，下拉列表显得尤为突出，有以下两个方面的原因：下拉列表通常查找大列表，下拉列表在读模式下也进行计算。
您可在自己的应用程序上执行一个简单的测试。以读模式打开一个其中的表单执行速度较慢的文档。打开文档时，仔细观察屏幕，找出其停顿的地方并做上标记。这 执行起来可能不太容易处理，因为您只有一秒钟的操作时间，然后屏幕就跳转了，但是如果能找人帮忙的话，则可由其中一人调用字段标签，同时由另一个人记下这 些标签。然后在 IBM Lotus Domino Designer 中打开表单并查看那些标记下的内容。最可能的情况是，您将发现标记所在之处是使用了 @DbLookup 公式的下拉列表。这是怎么回事？
以读模式打开文档时，将检验所有的 @DbLookup 公式。因为文档处于读模式下，所以并不会返回实际的检验值，但它们仍然会执行完该过程，而该过程很耗时。对于下拉列表，情况将更加糟糕，因为关键字字段由 用户选择的值填充，以防该用户切换到编辑模式。您可能认为可以等到用户切换至编辑模式，然后让用户做出选择，但 Lotus Notes 中并不是这样运作的。有趣的是，Web 浏览器中下拉列表却正是像那样运作，即使在相同的表单上运行也是如此。
一个很好用的清理下拉列表的技巧是：将三种不同的特性结合使用以防止执行不必要的查找。这些特性操作起来都很容易，但您必须将三者结合使用。
首先，在下拉列表字段的公式中，使用以下公式：
@If(@IsDocBeingEdited; “”; @Return(FieldName));
v := @DbColumn(“Notes”; “”; “(Lookup-Companies)”; 1);
@If(@IsError(v); “There are no company names”; v)
这与 “使查找频率最小化” 中描述的内容相似，并且在文档处于读模式时它可防止关键字下拉列表执行查找。如果用户以编辑模式打开文档，则下拉列表当然会正常地计算。现在我们必须确保用户从读模式转换到编辑模式时将会计算查找。为此，将继续执行下面两个步骤。
在下拉字段的属性中，启用 “Refresh choices on document refresh” 属性（参见图 2）。如果用户从读模式转换到编辑模式，则此属性可让关键字下拉公式在强制刷新文档时重新计算。
Add A Comment