工作流:Workflow

　　七、Notes应用系统

　　在进入开发组件的正题之前，我们先來聊聊什么是Notes应用系统。通常Notes应用系统也称为Notes应用程序、Notes AP…等等。尽管这些名词都不同，但其实都是指使用Domino Designer这个设计接口所开发出來的系统，像是请假系统、加班申报系统、请采购系统、文具申购系统、ISO文件管理系统，甚至是ECN系统、NBR系统…等等都属之。我想稍微列出这些系统名称，应该就可以稍微明了Notes不是只能用來当作电子邮件系统了吧。

　　一般初学者在还没开始真正了解Notes应用系统时，通常会认为一个资料库就是一支Notes应用系统。其实不尽然如此，绝大部分的Notes应用系统都是由一个以上的资料库所组成。

　　举例來說好了，就Louis的经验，建议刚导入Notes而且要开始开发系统时，第一优先开发的应该是人员组织资料库，这个资料库主要在储存企业人员组织信息，像是部门文件与人员文件。为什么要先开发建置这资料库呢??因为使用者在许多系统的窗体中，都有申请人的姓名、部门、工号…等等基本信息欄位，而这些欄位值强烈建议不要让使用者输入，而是由程序去人员组织资料库中自动搜寻并带出的（通常是利用@UserName取得的Notes名称來当作关键值）。所以，拿请假系统來說好了，既然请假系统会跨资料库到人员组织资料库取值，这就算是由兩个资料库來组成一个请假系统了。

　　当然，上述的例子是比较小型的例子，若要說又大型又比较有名的例子就属Lotus Workflow了，因为其每一支系统都至少要有三个资料库所组成－应用程序资料库、人员组织资料库、过程定义资料库、设计储存资料库（选择性）。

　　所以总结來說，一支Notes应用系统可以由一个或一个以上的Notes资料库所组成。

　　注：若您对人员组织资料库没有什么观念的话，可以參考DominoClub网站的SnowMan专欄中的简易员工资料库。虽然SnowMan兄谦虚的說那是「简易」员工资料库，不过其实该有的基本组件都已经有了，可說是麻雀虽小五脏俱全。各位只要依据各公司自己的需求再添加欄位就可以很完整了。网址如下：
http://www.domino.idv.tw/bbs/bbs2002...B?OpenDocument

　　八、欄位－Item与Field

　　应该会有朋友觉得奇怪，为何Louis不是先介绍文件或是套表，反而是先介绍欄位呢??其实我在下笔时也有考虑过这问题，之后一方面认为如果先讲文件与套表，可能要花比较多的时间与篇幅写；另一方面觉得欄位是最基础的观念，而且在說明欄位观念时也会稍微补充套表与文件的观念，所以决定先說明欄位。

　　Item与Field的中文翻译通常都是「欄位」，所以常被搞混，但兩者其实是完全不同的。严格來說，Item是要透过文件属性方块才可以看到的后端欄位；Field则是在套表上才能看到的前端欄位。以下是针对兩者的特性期之间的关連性加以說明：

　　（一）Item
　　Notes资料在储存上最基本的容器就是item。它可以储存文字、數字、日期时间、附加档案⋯等等资料。也由于是储存容器，所以要在文件储存后才会产生，若文件还没储存是不会有Item存在的，您可以试着开启一份新文件，然后打开文件属性方块看看就知道了。所以简而言之，文件其实就是由item所组成的。Item本身也有其属性，例如储存在item中的资料长度、资料類型⋯等等。而这些也可以从文件属性方块看到。

　　（二）Field
　　至于Field，简单來說，在新文件上是要让使用者输入资料；而在已存在的文件上，则是用來显示及编辑已储存于Item中的资料，所以称之为前端欄位，也就是說Field是用來与使用者互动的一个设计组件。既然是与使用者互动的设计组件，那就一定有某些方法可以达成此目的，就是透过field的程序，像是默认值公式、转译公式、验证公式、數个事件都可以让程序设计师撰写程序以达到上述的互动目的。

　　（三）Item与Field的連结
　　既然item是后端欄位，field是前端欄位，那就一定有方法将兩者連结起來。举例來說，在一般狀况下，若在套表上有一个名为X1的field，当文件储存时，在此欄位中的數值就会储存到名为X1的item中。再假设一种狀况，假设套表上有一个名为X1的field，在文件中另有一个名为Y1的item，若要将Y1的數值显示在X1 field的话，只要在X1 field的默认值公式或是计算公式填入Y1这个item名称即可。

　　（四）LotusScript的Item与Field
　　因为这种前后端结构的观念，所以在LotusScript中的NotesDocument類别下提供几个方法來操作处理item，像是GetFirstItem、GetItemValue…等等。如果程序设计师想要进一步处理item，则可以使用NotesItem的類别。这類后端的類别与方法通常是用來处理item中的數值。
　　至于操作处理Field的相关方法则被放在NotesUIDocument前端類别中，像是FieldGetText、FieldSetText⋯等等。这類前端的類别与方法通常是用來与使用者达到互动。

　　九、套表

　　就官方的定义而言，套表是用來显示动态信息的。既然是显示动态信息，就表示其中的信息是要让使用者可以看的到，更深入一点，就是让使用者可以透过套表來跟资料库中的资料作互动。所以套表在Notes中真的占有很重要的地位，而且应用层面甚广，例如，单纯显示文件中的信息、让使用者输入资料以建立文件、编辑文件中的资料以更新信息、在套表事件或是其它组件加入程序以运算处理文件中的资料…等等。在ND6中则可以直接查询RDB中的资料。ND7开始更可以和DB2资料库做资料交易。

　　但是，回到原点，没有任何其它设计组件存在的空套表是没有实质意义的。所以当套表中存在field、按钮、动作按钮、小节、焦点信息、有程序的事件…等等设计组件，才能发挥出套表的功效。相对于文件是许多item的容器，套表则是许多设计组件的容器。例如在Web上可以在套表中嵌入视界來美化视界在Web上的呈现。

　　再回到套表最主要的功能－建立与编辑文件。就建立新文件而言，当使用者在各field中输入數值并储存以后就会产生一份文件，而field中的數值则会储存到该文件中的各item中。另一方面，当使用者利用套表开启已经存在的文件时，套表的field通常就是用來显示或编辑item的數值。

　　十、文件
　　
　　其实在上述中差不多已经把欄位、套表、文件的关系解释的差不多了。所以在这儿我们就只稍做补充。

　　由于Item无法自行存在，而是必须存在于文件中，所以换言之，Notes文件可以說是包含一个以上Item的集合，这可說是一个抽象的观念。其实有些人会认为视界有显示出來或是套表可以打开的才算是文件，但其实不然，因为文件也有可能是「隐藏」在资料库中而不显示的。这就是常有人会看到工作区的资料库显示有未阅讀文件，但又在视界中找不到的原因。

　　另外，也有些人会认为文件跟套表是一体的，事实上也不然，套表与文件是分开的，就如同先前曾经提到，套表是为了让使用者可以新增、编辑、显示文件的。但也有例外，如果在套表属性中有勾选文件与套表一起储存的属性时，文件与套表就会储存在一起，但通常不建议如此做。因为把套表中的所有设计组件与文件合并储存在一起，就会让文件的体积变大，进而占用硬盘空间。就像是本來只有55公斤的Louis穿上几件衣服后，可能就增加到57公斤了。

　　另外，在Notes中还有一种特殊文件，就是设计文件，也就是开发者开发出來的设计组件，像是套表、视界…等等，也是以文件型态存在的，这些文件统称为Design Notes，不过当然也可以称为Design Document。在Domino Designer的设计组件清单中，使用滑鼠右键单击任一组件，都可以看到该设计组件的文件属性。顺带一提，在早期Notes文件并不称为Document，而是称为note，所以才有Lotus Notes这名字出现。

　　但是把话說回來，因为Notes文件的资料并无法像关聯式资料库可以利用key值把各资料做互相关聯，所以产生一些资料处理上的不便。不过这類问题通常还是可以经由技术上來解决的。而且也因为如此，Notes才能成为各种关聯式资料库的整合接口，不是吗？