跨多个数据库的Xpages

时间:2014-02-26 09:45:10

标签: xpages

我们将从XPages开始,我有以下问题:

我们有一个由多个Notes数据库组成的系统。现在我们都想添加一个XPage,这样就可以在浏览器和客户端进行编辑。 现在更好的是: 从其他数据库中获取具有XPages和编程和数据的数据库。 所有数据库都获得XPages,并通过导航单独解决。

对我而言,表现更好。

1 个答案:

答案 0 :(得分:11)

最佳做法是将每个“应用程序”的所有XPage设计元素存储在单个NSF中。这个可以与某些数据是同一个容器,或者它可以完全是一个单独的NSF。但是你应该肯定避免的是将XPage元素存储在单独的NSF中,因为数据恰好存储在几个NSF中。

相反,在XPage应用程序中,数据应始终被视为在哲学上与用户界面分开,即使 存储在同一NSF中。这种理念使得为应用程序设计现代,直观的用户界面变得更加容易,而不会仅仅根据后端数据的结构限制这些设计决策。

每个NSF的ACL仍然受到尊重,因此如果您为每个数据库强加了不同的访问级别,则用户仍然只能根据包含每个记录的NSF的ACL访问他们有权访问的内容。 ,无论包含XPage设计元素的NSF的ACL如何。

一个相当具体的性能考虑因素是application scope和会话范围对于包含用户当前正在访问的XPage元素的NSF都是唯一的。因此,如果您的应用程序由6个数据库组成,并且您将XPage设计元素拆分为这些数据库,则无法在所有应用程序中缓存配置设置或其他计算成本高昂的查询。相反,如果所有XPage设计元素都在一个NSF中,那么您只有一个应用程序范围。因此,用户界面的每个部分都可以访问已经由界面的任何其他部分缓存的信息 - 不仅跨越应用程序中的不同页面,还跨越用户:如果为一个用户检索的数据应该是相同的数据返回给所有用户,缓存它为一个人缓存它。

类似地,由于用户将在他们访问的每个NSF中具有不同的会话范围,因此当用户导航到不同的NSF时,将忘记适用于应用的所有区域的任何用户偏好(或行为)。

在不同的NSF中存储不同的XPage元素只是因为数据所在的位置会消除这些以及其他性能和界面优化的机会。对于那些刚接触这种类型的开发的人来说,分离设计可能会感觉更简单,但最终用户体验必然会受到影响,可能会以他们有意识地意识到的方式。但通常他们会感到困惑和沮丧,无法准确找出原因。

简而言之,这是确定每个XPage应该位置的 最佳 方式:如果最终用户从一个XPage导航到另一个XPage将假设他们仍然在同一个应用程序中,然后两者都应该在同一个NSF中,无论每个XPage访问的数据位置如何。