由 simpleflow » 2009-10-17 22:00
一、前言
许多初学Lotus Notes（LotusNotes以下简称Notes）的朋友常常会因为Notes学习范围太广、教育训練课程太贵、中文资料太少⋯等等因素，而不知该从何开始入门学习。不过因为这些因素而放弃的话，其实是非常之可惜的，毕竟Notes的功能及其整合性在群组软件領域中，仍然是領先其它群组软件的佼佼者。
Louis为了让许多初学Notes的朋友可以快速上手，所以决定着手撰写此系列的文章，希望以最浅显易懂的白话文來为初学者建立Notes程序设计最基本的观念（但会不会中断不敢保证:p）。不过既然是「随笔」，所以一些顺序的编排就不会那么的有系统。另外，在章文中虽然偶尔会提到一些技术观念，但并不属于高深的技术文件，纯粹只是观念养成的文章。若您想进一步了解文中提及的观念时，Louis「强烈」建议直接參考Notes程序设计說明资料库。当然，本系列文章中若有讹误还请各位前辈高手多多指教。
二、Notes学习方向
Notes的学习方向主要分为程序设计与系统管理兩部份，一般通称为Notes AD（ApplicationDevelopment）与SA（SystemAdministration），而这也是IBM官方的說法。不过，有时候AD也有人称为AP，而SA则常会与IT界常用的系统分析（SystemAnalysis）搞混，所以在与其它朋友交流时可千万不要鸡同鸭讲。
但不論是NotesAD还是SA的知識，这兩者并无明确界线，而且兩者其实是相辅相成的。以ACL的设定來讲，就无法明确归纳至AD或SA任一范畴，因为不管是在开发应用程序（应用程序以下简称AP）或是管理Domino系统，ACL的设定都是必须的常識。另外，在开发WebAP时，为了让浏览器使用者可以正常浏览存取Web AP的内容与资料，也须要先在服务器上做一些设定，而这也是开发人员所须要了解的。
所以就Louis个人的观点而言，千万不要将自己的角色局限在程序设计师或系统管理员而排斥学习任何一方面的知識。因为如此只会让您在执行一些任务时捉襟見肘罢了。接下來就让我们进入的正题吧!!
三、Notes资料库的分類与基础结构
在学习Notes AP开发的第一步骤，就是要先对Notes资料库有所了解，如此才不会因为观念不足或是错误而导致在开发过程中产生阻碍。所以Louis先整理一些观念让您稍微了解：
Top
（一）Notes资料库的分類
以目前市场上的资料库产品而言，就资料型态、功能性或配置方式分成好几類，例如最常听到的就是关聯式资料库（RelationalDatabase），通常简称为RDBMS或是RDB，而最具代表性的就是Oracle、DB2、Informix、SQL⋯等等，不过这都是要付授权费，如果是免费的，目前最红的该属MySQL了(Notes都可以跟这些资料库整合喔~~)。
就资料型态而言，Notes属于文件式资料库而非关聯式资料库。很多初学Notes的朋友对文件式资料库这名词通常都会很疑惑，一是因为网路上很难找到相关信息，二是对Notes还不是很了解。不过在之后的内容中Louis会陸续說明文件的观念。
就资料库的配置方式而言，Notes则被归類在分布式资料库，为什么呢？因为Notes
的资料库可以藉由抄写机制，将各资料库抄本分置到各服务器与客户端中。分布式资料库的理論在网路上有很多资料，若有兴趣的话可以到各大搜寻引擎网站找找。
（二）Notes资料库的结构
每一个Notes资料库在windows OS下是以档案格式存在的，其扩展名通常是NSF，也就是Notes StorageFacility的简写，翻译成中文就是Notes储存设备。至于扩展名NTF也是Notes范本资料库，全名是Notes TemplateFacility，是用來产生一般资料库的范本。也就是說，您可以利用模板资料库來新建一个资料库，而此资料库中的设计是与模板资料库的设计一模一样的。
按照官方的說法，每个Notes资料库是由四个基本组件所组成：
1.ACL：
就是Access Control List，一般翻译成存取控制清单，或是权限控制清单，顾名思义就是让资料库管理员可以指定使用者对该资料库执行何种动作。
2.设计组件：
是指套表、视界、外框、图文框、領航员⋯等等组件，而这些都是Notes资料库最最基础的组件，也是用來让资料库可以与使用者互动的基本组件，没有这些组件，资料库即无法运作。
3.所谓邏辑：
是指程序设计师在资料库中所撰写的程序语言，Lotus Script、公式、代理程序都是。主要是要运算处理资料库中的资料，或者达成某些自动化的作业。
4.资料：
是指储存在文件中的文字、數字、日期时间、附加档案⋯等等信息。
四、资料的安全控管
若要简单描述Domino对资料的安全控管，基本上由外而内可以分成几关：服务器è资料库è文件è隐藏公式。
以服务器这一关來說，是在服务器文件中控管的，例如允许或不允许哪些使用者存取此服务器、允许或不允许哪些使用者可以在服务器上建立或删除资料库…等等。
若是使用者被赋予存取服务器的权限，就会进入到资料库安全控管这关，而这关的安全控管就是由资料库ACL來决定的。
再來是文件的安全性控管，这是经由套表属性之安全卷标下的选项，以及讀者与作者欄位來处理的。
最后就是隐藏公式，其实，隐藏公式根本就不算是安全性控管的方法，这只能說是开发技巧。因为即使透过隐藏公式把套表中的特定欄位隐藏起來，使用者仍然可以透过文件属性方块看到各欄位中的资料。
Top
五、ACL
既然我们在前面多次谈到ACL，不稍微跟他交个朋友好像說不过去，所以在这儿就为大伙儿引荐他吧，呵呵。在ACL中主要有几种组件设定：使用者類型、权限類型、执行动作。
设定使用者類型是为了避免ID被误用。举例來說，通常服务器在资料库ACL中都是管理员权限，假设服务器ID被有心人士盗用，可能就会造成极大的破坏。所以为了防范有心「人」士进行这种破坏行动，就必须在ACL中正确设定为服务器類型，如此该人士即使拿到服务器ID也没办法使用Notesclient來对资料库执行任何活动。因为，服务器不是「人」，所以不会使用Notesclient（不过在系统管理中，Louis强烈建议把服务器当作是「人」，这样有助于管理概念的建立）。但相对的，如果未设定适当的類型，也会导致某些动作无法执行。
再來是权限類型，依权限低高依序有七层－没有权限、储存者、讀者、作者、编辑者、设计师、管理员。【没有权限】当然就不能对资料库执行任何动作，因为連进去的权利都没有。Louis常戏称【储存者】为工讀生权限，储存者仅能输入资料到资料库中，输入完毕后，就无法再看到这些资料。感觉就像找了一位工讀生來key in大量资料到资料库中，但又不想让工讀生记起这些资料或是看到其它资料。
先假设文件或套表中没有讀者欄位，当使用者被赋予【讀者】权限时，使用者就只能阅讀文件，而不能编辑文件，当然更不可能建立文件（可执行动作之建立文件选项被强制disable了）。不过，一但文件中有讀者欄位，若使用者的名称未在讀者欄位的名称清单之中，则即使有再高的ACL权限还是无法阅讀该文件。
至于【作者】权限就必须跟【作者】欄位配合使用才具效用，当使用者被赋予【作者】权限，但作者欄位中的使用者名称却是别位使用者时，这时即使该份文件是目前使用者所建立，但因为其名称未列于作者欄位中，所以无法编辑该文件，仅能阅讀而已。顺带一提，如果使用者被赋予【编辑者】(含)以上权限，但文件中的作者欄位中并没有这位使用者名称，使用者还是可以编辑文件，因为【作者】权限必须跟【作者】欄位配合使用才具效用，也就是說【编辑者】(含)以上权限不受作者欄位的约束。
至于【设计师】权限就是多了使用Domino Designer來开发AP的权限。而管理员则是多了修改ACL的权限。
兹概略整理下表以供參考：
管理者 设计者 编辑者 作者 讀者 储存者 没有权利
ACL设定 V
建立修改设计组件 V V
编辑所有文件 V V V
编辑自已文件 V V V V
增加新文件 V V V V V
读取所有文件 V V V V V
在资料库建立时，会在ACL的使用者清单中看到-Default-这笔项目。-Default-的作用是，当使用者在ACL中找不到适用于自己的权限时，就套用-Default-的权限。也就是說，凡名称未明列在ACL中或未包含在ACL的群组中，就套用-Default-的权限。在开发AP时若无特殊需求，-Default-通常都设定为编辑者。
您还会看到LocalDomainServers群组与OtherDomainServers群组。顾名思义，只要是与目前资料库的所在服务器位在同一Domino网域的服务器都会自动包含在LocalDomainServers群组中，除非您去names.nsf中更改此群组文件，那又另当别論了Orz。所以此群组预设权限是管理员，主要是为了让相同网域内的服务器可以进行抄写作业。至于OtherDomainServers群组就是跟LocalDomainServers相反了，因为此群组的成员均为不同网域外的Domino服务器，而且预设是无权限。有些集团企业因为有一个以上的Domino网域，所以可能会利用此群组來达到某些跨网域存取的需求。不过，在达成此類需求时，请先手动把那些位于不同网域的服务器名称加到names.nsf中的OtherDomainServers群组文件喔。
最后要谈到Anonymous这个特殊项目，这是要手动新增给Web AP使用的。也就是当未透过Web ID &Password登入的使用者，均会被视为匿名者并套用Anonymous项目的权限。若WebAP未设定此项目时，当您使用浏览器开启资料库时，系统就会给您一个警告，要求您到ACL中新增此一项目喔。请特别注意，在开发WebAP时若无特殊需求，请将此项目设为无权限，否则您资料库中的资料可能就会在网路上趴趴造了~~。
七、Notes应用系统
在进入开发组件的正题之前，我们先來聊聊什么是Notes应用系统。通常Notes应用系统也称为Notes应用程序、NotesAP…等等。尽管这些名词都不同，但其实都是指使用DominoDesigner这个设计接口所开发出來的系统，像是请假系统、加班申报系统、请采购系统、文具申购系统、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则是在套表上才能看到的前端欄位。以下是针对兩者的特性期之间的关連性加以說明：
Top
（一）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的數值。
Top
十、文件
其实在上述中差不多已经把欄位、套表、文件的关系解释的差不多了。所以在这儿我们就只稍做补充。
由于Item无法自行存在，而是必须存在于文件中，所以换言之，Notes文件可以說是包含一个以上Item的集合，这可說是一个抽象的观念。其实有些人会认为视界有显示出來或是套表可以打开的才算是文件，但其实不然，因为文件也有可能是「隐藏」在资料库中而不显示的。这就是常有人会看到工作区的资料库显示有未阅讀文件，但又在视界中找不到的原因。
另外，也有些人会认为文件跟套表是一体的，事实上也不然，套表与文件是分开的，就如同先前曾经提到，套表是为了让使用者可以新增、编辑、显示文件的。但也有例外，如果在套表属性中有勾选文件与套表一起储存的属性时，文件与套表就会储存在一起，但通常不建议如此做。因为把套表中的所有设计组件与文件合并储存在一起，就会让文件的体积变大，进而占用硬盘空间。就像是本來只有55公斤的Louis穿上几件衣服后，可能就增加到57公斤了。
另外，在Notes中还有一种特殊文件，就是设计文件，也就是开发者开发出來的设计组件，像是套表、视界…等等，也是以文件型态存在的，这些文件统称为Design Notes，不过当然也可以称为Design Document。在DominoDesigner的设计组件清单中，使用滑鼠右键单击任一组件，都可以看到该设计组件的文件属性。顺带一提，在早期Notes文件并不称为Document，而是称为note，所以才有Lotus Notes这名字出现。
但是把话說回來，因为Notes文件的资料并无法像关聯式资料库可以利用key值把各资料做互相关聯，所以产生一些资料处理上的不便。不过这類问题通常还是可以经由技术上來解决的。而且也因为如此，Notes才能成为各种关聯式资料库的整合接口，不是吗 ^_^
十一、自我提升
当我写下这个标题时感觉有点心虚，因为好像在灌水，呵呵。不过相信接下來Louis所說的，绝对是让各位初学者非常受用的。
一般刚开始开发NotesAP时，相信大部分使用者提出的需求都是主管去谈的，而您绝对是伤透脑筋在想功能写程序的那个人。虽然这是很一般的程序，但对于您的未來其实不見得是好处。虽然可以写出一支令使用者满意的AP绝对是一件很了不起的事，但是当您完成这支AP以后除了学到很多程序技巧与成就感以外，您还获得了什么？这是非常值得思考的一件事。
Notes的精髓在于签核流程的开发，而签核流程的精髓则是各产业的Domain KnowHow，也就是各产业的专业知識。所以当您接下主管交付的需求后，并非一味的埋头苦思程序该怎写、功能该怎开发，更重要的是去了解此系统的真正目的是什么、流程为什么要这么跑、使用者在签核底下的作业是什么。所以您应该再找机会去跟提出需求的使用者了解他们的作业程序，进而从他们的脑袋裡学习他们領域的专业知識。
其实，我常常在跟使用者谈需求的时候，即使懂也装不懂，很有禮貌的请使用者重头讲一次，反正被骂笨也无所谓，因为目的已经达到，大不了晚上抱着枕头哭一下就好了，隔天又是好汉一条，哈哈。
当您在各产业待过以后，这些知識就会逐月逐年累积成为您的宝藏。而这些宝藏将会在以后成为您闯荡江湖的宝刀。因为往后当您在与使用者谈需求时，由于您的宝藏取之不绝用之不尽，频频点头称是的将不再是您而会是使用者。
我相信应该很少朋友希望自己永远靠写程序维生，尤其到了一定年纪以后，写程序反而是一种负担。所以接下來赖以维生的将会是您的Domain KnowHow，帮您赚钱的绝对是您的脑袋与口才，而不是写程序的技术。这时应该要很高兴您不是修计算机的信息人员，而是写Notes的人员。所以，趁现在赶快累积您未來的财富吧!!加油!! 加油!! Go!! Go!! Go!!
嗯..还没结尾..请继续阅讀..感恩Orz
十二、视界
在随笔（二）中，Louis跟各位讨論到文件与套表的关系，所以接下來，我们就來谈谈视界吧。
视界这个设计组件，很多人都会把它拿來跟RDB（关聯式资料库）的table作比较。其实是有那么点像，所以在ND7才会改良出SQLQuery视界这玩意儿。不过，撇开视界与table的比较，视界的主要功能是为了有系统的整理资料库中的一大堆文件，将这些文件中的关键信息分门别類的「显示」出來，好让使用者可以快速找到他们所需要的信息。所以您要說视界是由一大堆文件所组成也不为过。但因为是给使用者使用的，所以在设计一个视界的时候，最好可以先与使用者讨論清楚，否则被要求重排视界的可能性非常的大。
不过，若从设计面來看，视界应该說是由直欄所组成，毕竟没有直欄的视界是没有任何用处的。在前面，我曾经把「显示」这兩个字特别标出來的原因是，直欄除了可以直接显示文件的欄位值以外，您也可以透过直欄公式來处理多个欄位值后再将其显示出來。也就是說，处理过后的直欄值并非储存在文件中，而仅供「显示」。优点在于，您不用在文件中放一大堆计算欄位來储存一些只为了「显示」用的數值。但缺点是，若直欄中有太多的计算公式，则视界的负担就会加重，因为它必须要计算每份文件的欄位值。当文件數量很多时，其负担是可想而知的。
我想大部份的初学朋友都知道「视界选择」这玩意儿吧，这玩意儿讲明白一点就是透过您指定的条件來筛选要显示在此视界的文件。最不严谨的条件当属【select @all】，因为它会将资料库中所有的文件通通显示在此视界中。最常看到的条件应该是【selectform=”套表名”】，视界会根据您所指定的套表名來搜寻并显示使用此套表建立的文件。当然您也可以搭配更多的条件设定來更进一步筛选文件，像是某个欄位等于、大于，或小于某个值。
有人可能会发现在「视界选择」下面有个「套表公式」，Louis曾经遇到一位我觉得还不错的程序设计师，但他却从來没用过「套表公式」。这真的是很重要的功能，但我要在此卖个关子，之后会搭配其它功能來說明。
另外，如果您已经熟悉公式与LotusScript的话，相信您一定常用到@DBLookup、@DBColumn、GetDocumentByKey、GetEntryByKey…等等搜寻類函式与方法。使用这類程序的第一要件当然就是要把视界中的第一直欄设定为排序。不过，Louis要讲的重点不是这个，我要讲的是…ㄜ…忘记要讲啥了…果然年纪到了就是会这样..><..（一分钟后）对了!!我要讲的是…当您在设计视界时，请尽量将程序用的视界与使用者用的视界分开，因为当资料库中有很多视界时，若您共享这兩种视界又没特别注明的话，哪天使用者要求您重排视界，结果运气不好的您移动到程序用视界的第一直欄，那就糗大了，因为一定会有程序找不到符合的关键词资料，而这很有可能让您花上大半天去找虫虫何在。至于要怎标示，把视界名称括号起來就好了，要不就在视界属性的注明欄位注明。不过Louis偏好前者，因为前者可以把视界隐藏起來，也就是說，当使用者按下【检视】 【移至】也看不到那个视界，除非他们知道按下Ctrl + Shift +【检视】【移至】（又学一招了吧，呵呵）。
既然刚刚提到GetDocumentByKey与GetEntryByKey这兩个method，就顺便提一下这兩者的差别。如果您曾使用侦错器观察的话，就会发现前者是传回文件对象，所以理所当然会把文件中的所有欄位值还有一堆属性通通抓出來，而后者就只会抓到视界中直欄值。这有什么影响吗？当然有影响啰！使用GetDocumentByKey与GetEntryByKey可能还察觉不出來，当您使用GetAllDocumentsByKey与GetAllEntriesByKey來传回上百笔的资料，相信您就可以察觉到Server Loading的不同了。
十三、资料夹
既然谈到视界，就不得不來谈资料夹。这裡的资料夹当然不是指Windows的资料夹，Louis要說的是Notes的设计组件之一的那个资料夹。资料夹跟视界非常之像，我们可以說它们是龍凤胎也不为过，因为最明显的差别在于”视界选择”。ㄜ..没有「视界选择」那怎筛选文件啊！？既然没有「视界选择」当然就是有其它的方法可以筛选啰。资料夹筛选文件的方式可以透过程序或使用者手动筛选（复制或剪下，然后贴上）。换句话說，资料夹内的文件主要是由程序或使用者手动置入的。
资料夹应用的最彻底的当属邮件资料库了，收件匣各位应该很熟悉吧，它老兄就是资料夹而不是视界，从R5的邮件资料库可能还看不太出來哪些是资料夹，哪些是视界，但从R6的邮件资料库就比较容易分辨了，因为它多了一个「视界」的展开项目，在裡面的全部都是视界。不过在「视界」的展开项目以外还是有视界的。若要真正去辨别的话，还是要从Notes Designer比较明确一点。
先来解释「手动」放文件到数据夹的观念吧。假设A视界与B视界的视界选择条件一样，其所筛选出來的文件其实都是同一份文件。但是，当您在C资料夹与D资料夹中各看到一份几乎是一模一样的文件，在资料库中它们『可能』不是同一份文件，而是兩份文件，原因在于资料夹是独立的个体，所以手动个别贴上的话就会是两份文件。简单來說，资料夹的文件是被「放」进去的，视界的文件是被「筛选」出來的。这样您应该就懂了吧，再不懂，那就请您去邮件资料库多玩几次复制或剪下，然后到处贴上的游戏啰。好吧，再鸡婆举例說明一下：
1.当您从A视界中复制一份文件，然后贴到C资料夹，此时C资料夹有一份文件，D资料夹会是空的，A视界则变成兩份文件。
2.再到D资料夹贴上那份文件，这时C资料夹还是只有一份文件，D资料夹当然也只有一份文件。但是，回过头來看原來的A视界，您会发现A视界中会变成三份文件。
3.这三份文件=原來的文件＋C资料夹的文件＋D资料夹的文件。其实从文件属性中可以看到这三份文件的UNID其实是通通不一样的。
以上都是手动放文件到数据夹的观念，接下来就是「程序」放文件到数据夹的观念了，使用NotesDocumentCollection.PutAllInFolder将文件放到数据夹中时，文件并没有增加，因为PutAllInFolder并不是「复制->贴上」文件，而是帮助数据夹「筛选」出符合条件的文件再「显示」出来。所以来源视界与数据库中的文件是不会增加的。
资料夹有一个很好用的功能－排序。当您使用GetAllDocumentsByKey从视界取得某些文件时（NotesDocumentCollection），这些文件并不会按照原视界的排序一份份排好，所以如果当您的需求是要「依照某种顺序」來处理这些文件的话，您可以先建立一个资料夹，并将此资料夹的排序设定成您想要的，再用PutAllInFolder方法把文件通通「显示」到里面进去，这样您的文件就会照顺序排了。不过请记得，处理完请务必记得再使用RemoveAllFromFolder把那些文件从资料夹删除。否则这资料夹中的文件会一直增加，这样就会造成之后所处理的文件不是当次放进去的文件，而是累积已久杂七杂八的文件。
十四、随处可得的文件
这一篇是要响应某位匿名朋友的问题－何谓前端文件、后端文件、屏幕上看到的文件、内存中的文件、数据库中的文件？其实在前面几篇中，已经有谈到文件的观念，不过没有以这几个项目来做区分说明就是了，所以这部份我们就当作再次温习文件的观念吧!!再者，路哥认为这问题以一位初学朋友而言问得实在是很不错。而这问题我相信也是众多初学者的问题!!
1.后端文件
后端文件的产生基本上可以分成两种－透过套表产生与透过程序产生。前者当然是由使用者开启套表，并在相关字段输入数据后「储存」产生的。后者则是透过Lotus Script或Java产生的，例如Set doc = New NotesDocument(NotesDatabase)……Calldoc.Save(True,True)。您看看，这两者都有「储存」的程序喔，如果没有储存的程序，文件就不会在数据库中产生。当文件进入到数据库中时，我们就可以称它们为后端文件了。而在Lotus Script中是以NotesDocument类别来实现的。
所以，只要是已经经过储存的文件，我们就可以统称为数据库中的文件。
2.前端文件
至于前端文件就很简单了，不管是新文件或是原本就已存在于数据库中的文件，只要是透过套表呈现到屏幕上的就都叫做前端文件。所以其实屏幕上看到的文件就等于前端文件，其主要的作用在与使用者达到互动。在Lotus Script中则是以NotesUIDocument类别来实现的。
3.后端文件与前端文件的关系
同一份文件会不会同时拥有前端文件跟后端文件呢？答案是「不一定」。
在前面的随笔中有提过，利用套表开启一份新文件时（也就是前端文件），打开文件属性方块后是看不到什么较实际的信息的，因为还没经过储存程序，也就是说未储存的新文件就只有前端文件。
但用套表开启一份已存在于数据库中的文件时，在屏幕上看到的就是前端文件，您在上面修修改改尚未储存的数据均可视为前端文件的部分。但此时开启文件属性方块，您可以看到此文件的相关属性与各字段数据，这部份则是属于已储存之后端文件的部份。若您在此时按下储存，前端文件的数据就会更新到后端文件中了。这就是前端文件与后端文件并存状况。
至于在Lotus Script中怎么透过前端文件来取得后端文件呢？只要使用NotesUIDocument.Document即可，因为NotesUIDocument代表目前开启的前端文件，而Document则是指目前文件的后端文件。
4.内存中的文件
这部份麻，我想就跟Lotus Script或Java程序设计有关了，我尽量解释您就尽量看看，能吸收多少算多少。
在LotusScript中有NotesDocument与NotesDocumentsCollection的物件。当您使用GetDocumentByKey方法取得NotesDocument对象，或是使用GetAllDocumentsByKey取得NotesDocumentsCollection的对象时，被取得之文件对象所包含的所有数据都会被储存在内存中，等待您进一步的处理。
在前面路哥也提到过，若文件中有很多数据，则太多的文件就会造成内存的负担，所以，如果您只是很单纯的处理少数资料，就请尽量使用NotesViewEntry或NotesViewEntries，因为内存只会储存文件在此视界的直栏数据，而不会储存文件的所有数据。
5.结论
文件是很抽象的观念，我稍微将它具体化一下，但并非一模一样。数据库就类似公文柜，视界就有点像是公文夹，文件类似现实生活中的公文。如果没有公文夹视界来将文件分门别类的保存起来，数据库就会像是一个摆放了一大堆杂乱无章文件的公文柜。
我建议您可以再回到前面几篇温习一下，相信会有不同的感觉的。
十五、选择开启文件的套表
回到咱们的进度上吧，在本篇随笔中，这一节算是唯一在进度上的一节。路哥好像没有谈到有进度吧，因为进度在路哥的脑袋瓜子里，呵呵。
相信各位在看过前三篇随笔后，对文件跟套表的关系应该有一定程度的了解，所以接下来要为各位介绍的是，当您开启一份文件时Notes是如何决定要用哪一张套表来显示文件。
不懂路哥在说什么吗？没关系，我就再稍微解释一下，Notes文件并非只能使用当初建立此文件的套表来开启，也就是说一份文件可以使用不同的套表来开启，而产生的结果就是在前端呈现的文件之排版与数据会不同。例如，有A与B两张套表，A套表有两个字段－AAA、BBB；B套表只有BBB字段。另外在数据库中有一份文件储存了AAA字段值111与BBB字段值222。这时使用A套表开启甲文件时，您会看到屏幕上显示111与222两个字段值。接下来再用B套表开启甲文件，此时您就只会看到222而已。也就是说同一份文件会因为套表上的排版与字段不同而有不同的显示。
用最最最简单的实际例子来说明好了，假设路哥有两条牛仔裤，A牛仔裤的左边裤管剪了一个洞，而B牛仔裤则是在右边裤管剪了一个洞，当路哥穿A牛仔裤时就会露出左膝盖，穿B牛仔裤时则是露出右膝盖。即使你们会因为我穿不同的牛仔裤而看到不同的膝盖，但其实路哥本身还是有两个膝盖，并不会因为穿哪件牛仔裤而真的少了哪个膝盖。不过……路妈要是看到我穿这种牛仔裤，一定又会念说，你是没钱可以买裤子喔!! ><
好回到正题，Notes是如何决定要用哪张套表来开启文件的。采用顺序为，套表与文件合并储存à视界的套表公式à Form字段值à数据库的预设套表。说明如下：
1.套表与文件合并储存：这在随笔2中的第3页的倒数第三段有解说过，请自行回头参考。
2.视界的套表公式：这个就要特别解释了，因为曾经有两位从软件公司出身的朋友同时问过我一个问题就是，如何在视界中依不同的条件来选择不同套表开启文件。其实满惊讶的，因为我觉得这是非常基础的功能，而且是必须知道的。所以在此特别说明，答案是视界的套表公式，在哪儿呢？就在写视界选择公式下面的那个「套表公式」。
简单来说，您可以写一行程序，假设A字段值=1时就用A套表开启，否则就用B套表开启。所以当A字段值有所变动时就会使用不同的套表来开启文件。个人觉得这功能虽然很少用，但是，却是很好用的功能。
3.Form字段值：在Notes中有个保留字段叫做Form，而此字段值就是在储存用来开启文件之套表的名称，所以强烈建议使用Lotus Script建立新文件时都要指定此字段值（语法：doc.Form=”套表名称”）。
4.数据库的预设套表：在套表的设计属性的基础卷标下有一个「预设的数据库套表」选项，若勾选此选项后，前面所说的条件若都不成立时，就会采用勾选此选项的套表来开启文件。我想应该会有朋友问说，那要是有两张套表都有勾怎办？那您就勾勾看吧，呵呵。一个数据库只能存在一张预设套表，所以后勾的赢，也就是说若A套表勾了以后，B套表又勾，那系统就会自动取消A套表的该选项。
好，讲到这边整理一下，当您开启一份文件时，Notes会先参照文件当初储存时的那张套表是否有勾选「套表与文件合并储存」属性，若有则采用该套表开启。若没有就会参照视界的套表公式，所以若您有写套表公式时就会依照该公式的条件来开启文件。若没有写套表公式，那就会参照文件中的Form字段值，若文件中此字段值有指定套表名称，就会使用该套表来开启。若没有则会参照最后的防线－「数据库的预设套表」。若数据库中没有预设套表呢？如果路哥没有记错，系统好像会出现「找不到套表」之类的错误讯息。不过也有可能记错喔，最近脑筋不太灵光…呵呵。
十六、Lotus Script超基础观念
这是路哥突发奇想的主题，相信初学者的您在看完此节以后，一定会非常有收获唷!!
LotusScript是以对象为基础的程序语言，还谈不上是完全对象导向的语言。市面上有很多书籍在谈对象导向，好像一开始都是用车子或飞机来当例子，可是路哥总觉得缺少了什么。所以长久以来路哥一直很想找出某种生活上的实际情形来与LotusScript中的类别对象相对照，让初学者有很清楚的概念。在某天明月高挂的夜晚，终于让路哥顿悟了，就只差没成仙而已。因为是新的想法，所以各位这次就当作是路哥的白老鼠吧，感恩不尽，若有讲错的地方还多多海函 Orz。
在开始之前，路哥先声明不把所有的类别都拿出来讲，我只用了几个比较常用的类别，其余的就交给各位自行体会了。让我们开始吧!!
Lotus Script的特点之一，就是有很明确的对象阶层，而且大部份每一阶层对象皆会包含下一阶层对象（NotesItem是最底层对象，所以只有方法与属性）。
例如NotesSessionà NotesDatabaseà NotesViewàNotesDocumentà NotesItem。
精采的来了，我的虚拟实景是：
1.NotesSession = 地球，因为地球是一个大环境，包容各式各样的对象与数据。
2.NotesDatabase = 台湾，因为每个国家就像是一个数据库，有很多的文件跟视界存在。
3.NotesView = 县市行政区，每个县市可以视为一个view都是以现式的名称来将位于各地的房子筛选出来，所以NotesDocument=房子，如下说明。
4.NotesDocument = 房子，因为房子有很多数据，像是地址就可以比做是UNID，因为地址绝对不会重复。
5.NotesItem = 房子的基本数据，透过GetFirstItem就可以得到类似房子有几坪、户口数、在第几层…等等的信息。
所以呢，现在如果我们想要知道路哥房子的房间数，程序可以这样写：
Dim 地球 As New NotesSession
Dim 台湾 As NotesDatabase
Dim 台北县 As NotesView
Dim 路哥的房子 As NotesDocument
Dim 房间数 As NotesItem
Set 台湾 = 地球.CurrentDatabase
‘ 因为我们现在在台湾，所以就用CurrentDatabase
Set 台北县 = 台湾.GetView(“台北县”)
‘ 假设台北县这个View是以户长姓名为第一直栏而且有排序
Set 路哥的房子 = 台北县.GetDocumentByKey(“路哥”)
‘ 既然是要找路哥的房子，当然Key值就是”路哥”啰
Set 房间数 = 路哥的房子.GetItem(“房间数”)
‘ 因为要查路哥房子的房间数，所以就直接去找房间数这个字段，此时传回值会
是3，因为路哥的房子是三房两厅。
举一反三，如果要找路爸的房子呢（不是路霸喔，是路哥的老爹啦…哈哈），那就把Key值改成”路爸”，因为路爸也住台北县啰，这样就可以找到路爸的房子数据了。
如何，够清楚吧，为什么路哥会想用这种方式解释，是因为这样比较能够感觉出Notes是文件式数据库的感觉，至于市面上那些使用飞机、车子当作例子的书籍，我想作者们应该是为了表达对象导向的观念吧。
许多初学Lotus Notes（LotusNotes以下简称Notes）的朋友常常会因为Notes学习范围太广、教育训練课程太贵、中文资料太少⋯等等因素，而不知该从何开始入门学习。不过因为这些因素而放弃的话，其实是非常之可惜的，毕竟Notes的功能及其整合性在群组软件領域中，仍然是領先其它群组软件的佼佼者。
Louis为了让许多初学Notes的朋友可以快速上手，所以决定着手撰写此系列的文章，希望以最浅显易懂的白话文來为初学者建立Notes程序设计最基本的观念（但会不会中断不敢保证:p）。不过既然是「随笔」，所以一些顺序的编排就不会那么的有系统。另外，在章文中虽然偶尔会提到一些技术观念，但并不属于高深的技术文件，纯粹只是观念养成的文章。若您想进一步了解文中提及的观念时，Louis「强烈」建议直接參考Notes程序设计說明资料库。当然，本系列文章中若有讹误还请各位前辈高手多多指教。
二、Notes学习方向
Notes的学习方向主要分为程序设计与系统管理兩部份，一般通称为Notes AD（ApplicationDevelopment）与SA（SystemAdministration），而这也是IBM官方的說法。不过，有时候AD也有人称为AP，而SA则常会与IT界常用的系统分析（SystemAnalysis）搞混，所以在与其它朋友交流时可千万不要鸡同鸭讲。
但不論是NotesAD还是SA的知識，这兩者并无明确界线，而且兩者其实是相辅相成的。以ACL的设定來讲，就无法明确归纳至AD或SA任一范畴，因为不管是在开发应用程序（应用程序以下简称AP）或是管理Domino系统，ACL的设定都是必须的常識。另外，在开发WebAP时，为了让浏览器使用者可以正常浏览存取Web AP的内容与资料，也须要先在服务器上做一些设定，而这也是开发人员所须要了解的。
所以就Louis个人的观点而言，千万不要将自己的角色局限在程序设计师或系统管理员而排斥学习任何一方面的知識。因为如此只会让您在执行一些任务时捉襟見肘罢了。接下來就让我们进入的正题吧!!
三、Notes资料库的分類与基础结构
在学习Notes AP开发的第一步骤，就是要先对Notes资料库有所了解，如此才不会因为观念不足或是错误而导致在开发过程中产生阻碍。所以Louis先整理一些观念让您稍微了解：
Top
（一）Notes资料库的分類
以目前市场上的资料库产品而言，就资料型态、功能性或配置方式分成好几類，例如最常听到的就是关聯式资料库（RelationalDatabase），通常简称为RDBMS或是RDB，而最具代表性的就是Oracle、DB2、Informix、SQL⋯等等，不过这都是要付授权费，如果是免费的，目前最红的该属MySQL了(Notes都可以跟这些资料库整合喔~~)。
就资料型态而言，Notes属于文件式资料库而非关聯式资料库。很多初学Notes的朋友对文件式资料库这名词通常都会很疑惑，一是因为网路上很难找到相关信息，二是对Notes还不是很了解。不过在之后的内容中Louis会陸续說明文件的观念。
就资料库的配置方式而言，Notes则被归類在分布式资料库，为什么呢？因为Notes
的资料库可以藉由抄写机制，将各资料库抄本分置到各服务器与客户端中。分布式资料库的理論在网路上有很多资料，若有兴趣的话可以到各大搜寻引擎网站找找。
（二）Notes资料库的结构
每一个Notes资料库在windows OS下是以档案格式存在的，其扩展名通常是NSF，也就是Notes StorageFacility的简写，翻译成中文就是Notes储存设备。至于扩展名NTF也是Notes范本资料库，全名是Notes TemplateFacility，是用來产生一般资料库的范本。也就是說，您可以利用模板资料库來新建一个资料库，而此资料库中的设计是与模板资料库的设计一模一样的。
按照官方的說法，每个Notes资料库是由四个基本组件所组成：
1.ACL：
就是Access Control List，一般翻译成存取控制清单，或是权限控制清单，顾名思义就是让资料库管理员可以指定使用者对该资料库执行何种动作。
2.设计组件：
是指套表、视界、外框、图文框、領航员⋯等等组件，而这些都是Notes资料库最最基础的组件，也是用來让资料库可以与使用者互动的基本组件，没有这些组件，资料库即无法运作。
3.所谓邏辑：
是指程序设计师在资料库中所撰写的程序语言，Lotus Script、公式、代理程序都是。主要是要运算处理资料库中的资料，或者达成某些自动化的作业。
4.资料：
是指储存在文件中的文字、數字、日期时间、附加档案⋯等等信息。
四、资料的安全控管
若要简单描述Domino对资料的安全控管，基本上由外而内可以分成几关：服务器è资料库è文件è隐藏公式。
以服务器这一关來說，是在服务器文件中控管的，例如允许或不允许哪些使用者存取此服务器、允许或不允许哪些使用者可以在服务器上建立或删除资料库…等等。
若是使用者被赋予存取服务器的权限，就会进入到资料库安全控管这关，而这关的安全控管就是由资料库ACL來决定的。
再來是文件的安全性控管，这是经由套表属性之安全卷标下的选项，以及讀者与作者欄位來处理的。
最后就是隐藏公式，其实，隐藏公式根本就不算是安全性控管的方法，这只能說是开发技巧。因为即使透过隐藏公式把套表中的特定欄位隐藏起來，使用者仍然可以透过文件属性方块看到各欄位中的资料。
Top
五、ACL
既然我们在前面多次谈到ACL，不稍微跟他交个朋友好像說不过去，所以在这儿就为大伙儿引荐他吧，呵呵。在ACL中主要有几种组件设定：使用者類型、权限類型、执行动作。
设定使用者類型是为了避免ID被误用。举例來說，通常服务器在资料库ACL中都是管理员权限，假设服务器ID被有心人士盗用，可能就会造成极大的破坏。所以为了防范有心「人」士进行这种破坏行动，就必须在ACL中正确设定为服务器類型，如此该人士即使拿到服务器ID也没办法使用Notesclient來对资料库执行任何活动。因为，服务器不是「人」，所以不会使用Notesclient（不过在系统管理中，Louis强烈建议把服务器当作是「人」，这样有助于管理概念的建立）。但相对的，如果未设定适当的類型，也会导致某些动作无法执行。
再來是权限類型，依权限低高依序有七层－没有权限、储存者、讀者、作者、编辑者、设计师、管理员。【没有权限】当然就不能对资料库执行任何动作，因为連进去的权利都没有。Louis常戏称【储存者】为工讀生权限，储存者仅能输入资料到资料库中，输入完毕后，就无法再看到这些资料。感觉就像找了一位工讀生來key in大量资料到资料库中，但又不想让工讀生记起这些资料或是看到其它资料。
先假设文件或套表中没有讀者欄位，当使用者被赋予【讀者】权限时，使用者就只能阅讀文件，而不能编辑文件，当然更不可能建立文件（可执行动作之建立文件选项被强制disable了）。不过，一但文件中有讀者欄位，若使用者的名称未在讀者欄位的名称清单之中，则即使有再高的ACL权限还是无法阅讀该文件。
至于【作者】权限就必须跟【作者】欄位配合使用才具效用，当使用者被赋予【作者】权限，但作者欄位中的使用者名称却是别位使用者时，这时即使该份文件是目前使用者所建立，但因为其名称未列于作者欄位中，所以无法编辑该文件，仅能阅讀而已。顺带一提，如果使用者被赋予【编辑者】(含)以上权限，但文件中的作者欄位中并没有这位使用者名称，使用者还是可以编辑文件，因为【作者】权限必须跟【作者】欄位配合使用才具效用，也就是說【编辑者】(含)以上权限不受作者欄位的约束。
至于【设计师】权限就是多了使用Domino Designer來开发AP的权限。而管理员则是多了修改ACL的权限。
兹概略整理下表以供參考：
管理者 设计者 编辑者 作者 讀者 储存者 没有权利
ACL设定 V
建立修改设计组件 V V
编辑所有文件 V V V
编辑自已文件 V V V V
增加新文件 V V V V V
读取所有文件 V V V V V
在资料库建立时，会在ACL的使用者清单中看到-Default-这笔项目。-Default-的作用是，当使用者在ACL中找不到适用于自己的权限时，就套用-Default-的权限。也就是說，凡名称未明列在ACL中或未包含在ACL的群组中，就套用-Default-的权限。在开发AP时若无特殊需求，-Default-通常都设定为编辑者。
您还会看到LocalDomainServers群组与OtherDomainServers群组。顾名思义，只要是与目前资料库的所在服务器位在同一Domino网域的服务器都会自动包含在LocalDomainServers群组中，除非您去names.nsf中更改此群组文件，那又另当别論了Orz。所以此群组预设权限是管理员，主要是为了让相同网域内的服务器可以进行抄写作业。至于OtherDomainServers群组就是跟LocalDomainServers相反了，因为此群组的成员均为不同网域外的Domino服务器，而且预设是无权限。有些集团企业因为有一个以上的Domino网域，所以可能会利用此群组來达到某些跨网域存取的需求。不过，在达成此類需求时，请先手动把那些位于不同网域的服务器名称加到names.nsf中的OtherDomainServers群组文件喔。
最后要谈到Anonymous这个特殊项目，这是要手动新增给Web AP使用的。也就是当未透过Web ID &Password登入的使用者，均会被视为匿名者并套用Anonymous项目的权限。若WebAP未设定此项目时，当您使用浏览器开启资料库时，系统就会给您一个警告，要求您到ACL中新增此一项目喔。请特别注意，在开发WebAP时若无特殊需求，请将此项目设为无权限，否则您资料库中的资料可能就会在网路上趴趴造了~~。
七、Notes应用系统
在进入开发组件的正题之前，我们先來聊聊什么是Notes应用系统。通常Notes应用系统也称为Notes应用程序、NotesAP…等等。尽管这些名词都不同，但其实都是指使用DominoDesigner这个设计接口所开发出來的系统，像是请假系统、加班申报系统、请采购系统、文具申购系统、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则是在套表上才能看到的前端欄位。以下是针对兩者的特性期之间的关連性加以說明：
Top
（一）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的數值。
Top
十、文件
其实在上述中差不多已经把欄位、套表、文件的关系解释的差不多了。所以在这儿我们就只稍做补充。
由于Item无法自行存在，而是必须存在于文件中，所以换言之，Notes文件可以說是包含一个以上Item的集合，这可說是一个抽象的观念。其实有些人会认为视界有显示出來或是套表可以打开的才算是文件，但其实不然，因为文件也有可能是「隐藏」在资料库中而不显示的。这就是常有人会看到工作区的资料库显示有未阅讀文件，但又在视界中找不到的原因。
另外，也有些人会认为文件跟套表是一体的，事实上也不然，套表与文件是分开的，就如同先前曾经提到，套表是为了让使用者可以新增、编辑、显示文件的。但也有例外，如果在套表属性中有勾选文件与套表一起储存的属性时，文件与套表就会储存在一起，但通常不建议如此做。因为把套表中的所有设计组件与文件合并储存在一起，就会让文件的体积变大，进而占用硬盘空间。就像是本來只有55公斤的Louis穿上几件衣服后，可能就增加到57公斤了。
另外，在Notes中还有一种特殊文件，就是设计文件，也就是开发者开发出來的设计组件，像是套表、视界…等等，也是以文件型态存在的，这些文件统称为Design Notes，不过当然也可以称为Design Document。在DominoDesigner的设计组件清单中，使用滑鼠右键单击任一组件，都可以看到该设计组件的文件属性。顺带一提，在早期Notes文件并不称为Document，而是称为note，所以才有Lotus Notes这名字出现。
但是把话說回來，因为Notes文件的资料并无法像关聯式资料库可以利用key值把各资料做互相关聯，所以产生一些资料处理上的不便。不过这類问题通常还是可以经由技术上來解决的。而且也因为如此，Notes才能成为各种关聯式资料库的整合接口，不是吗 ^_^
十一、自我提升
当我写下这个标题时感觉有点心虚，因为好像在灌水，呵呵。不过相信接下來Louis所說的，绝对是让各位初学者非常受用的。
一般刚开始开发NotesAP时，相信大部分使用者提出的需求都是主管去谈的，而您绝对是伤透脑筋在想功能写程序的那个人。虽然这是很一般的程序，但对于您的未來其实不見得是好处。虽然可以写出一支令使用者满意的AP绝对是一件很了不起的事，但是当您完成这支AP以后除了学到很多程序技巧与成就感以外，您还获得了什么？这是非常值得思考的一件事。
Notes的精髓在于签核流程的开发，而签核流程的精髓则是各产业的Domain KnowHow，也就是各产业的专业知識。所以当您接下主管交付的需求后，并非一味的埋头苦思程序该怎写、功能该怎开发，更重要的是去了解此系统的真正目的是什么、流程为什么要这么跑、使用者在签核底下的作业是什么。所以您应该再找机会去跟提出需求的使用者了解他们的作业程序，进而从他们的脑袋裡学习他们領域的专业知識。
其实，我常常在跟使用者谈需求的时候，即使懂也装不懂，很有禮貌的请使用者重头讲一次，反正被骂笨也无所谓，因为目的已经达到，大不了晚上抱着枕头哭一下就好了，隔天又是好汉一条，哈哈。
当您在各产业待过以后，这些知識就会逐月逐年累积成为您的宝藏。而这些宝藏将会在以后成为您闯荡江湖的宝刀。因为往后当您在与使用者谈需求时，由于您的宝藏取之不绝用之不尽，频频点头称是的将不再是您而会是使用者。
我相信应该很少朋友希望自己永远靠写程序维生，尤其到了一定年纪以后，写程序反而是一种负担。所以接下來赖以维生的将会是您的Domain KnowHow，帮您赚钱的绝对是您的脑袋与口才，而不是写程序的技术。这时应该要很高兴您不是修计算机的信息人员，而是写Notes的人员。所以，趁现在赶快累积您未來的财富吧!!加油!! 加油!! Go!! Go!! Go!!
嗯..还没结尾..请继续阅讀..感恩Orz
十二、视界
在随笔（二）中，Louis跟各位讨論到文件与套表的关系，所以接下來，我们就來谈谈视界吧。
视界这个设计组件，很多人都会把它拿來跟RDB（关聯式资料库）的table作比较。其实是有那么点像，所以在ND7才会改良出SQLQuery视界这玩意儿。不过，撇开视界与table的比较，视界的主要功能是为了有系统的整理资料库中的一大堆文件，将这些文件中的关键信息分门别類的「显示」出來，好让使用者可以快速找到他们所需要的信息。所以您要說视界是由一大堆文件所组成也不为过。但因为是给使用者使用的，所以在设计一个视界的时候，最好可以先与使用者讨論清楚，否则被要求重排视界的可能性非常的大。
不过，若从设计面來看，视界应该說是由直欄所组成，毕竟没有直欄的视界是没有任何用处的。在前面，我曾经把「显示」这兩个字特别标出來的原因是，直欄除了可以直接显示文件的欄位值以外，您也可以透过直欄公式來处理多个欄位值后再将其显示出來。也就是說，处理过后的直欄值并非储存在文件中，而仅供「显示」。优点在于，您不用在文件中放一大堆计算欄位來储存一些只为了「显示」用的數值。但缺点是，若直欄中有太多的计算公式，则视界的负担就会加重，因为它必须要计算每份文件的欄位值。当文件數量很多时，其负担是可想而知的。
我想大部份的初学朋友都知道「视界选择」这玩意儿吧，这玩意儿讲明白一点就是透过您指定的条件來筛选要显示在此视界的文件。最不严谨的条件当属【select @all】，因为它会将资料库中所有的文件通通显示在此视界中。最常看到的条件应该是【selectform=”套表名”】，视界会根据您所指定的套表名來搜寻并显示使用此套表建立的文件。当然您也可以搭配更多的条件设定來更进一步筛选文件，像是某个欄位等于、大于，或小于某个值。
有人可能会发现在「视界选择」下面有个「套表公式」，Louis曾经遇到一位我觉得还不错的程序设计师，但他却从來没用过「套表公式」。这真的是很重要的功能，但我要在此卖个关子，之后会搭配其它功能來說明。
另外，如果您已经熟悉公式与LotusScript的话，相信您一定常用到@DBLookup、@DBColumn、GetDocumentByKey、GetEntryByKey…等等搜寻類函式与方法。使用这類程序的第一要件当然就是要把视界中的第一直欄设定为排序。不过，Louis要讲的重点不是这个，我要讲的是…ㄜ…忘记要讲啥了…果然年纪到了就是会这样..><..（一分钟后）对了!!我要讲的是…当您在设计视界时，请尽量将程序用的视界与使用者用的视界分开，因为当资料库中有很多视界时，若您共享这兩种视界又没特别注明的话，哪天使用者要求您重排视界，结果运气不好的您移动到程序用视界的第一直欄，那就糗大了，因为一定会有程序找不到符合的关键词资料，而这很有可能让您花上大半天去找虫虫何在。至于要怎标示，把视界名称括号起來就好了，要不就在视界属性的注明欄位注明。不过Louis偏好前者，因为前者可以把视界隐藏起來，也就是說，当使用者按下【检视】 【移至】也看不到那个视界，除非他们知道按下Ctrl + Shift +【检视】【移至】（又学一招了吧，呵呵）。
既然刚刚提到GetDocumentByKey与GetEntryByKey这兩个method，就顺便提一下这兩者的差别。如果您曾使用侦错器观察的话，就会发现前者是传回文件对象，所以理所当然会把文件中的所有欄位值还有一堆属性通通抓出來，而后者就只会抓到视界中直欄值。这有什么影响吗？当然有影响啰！使用GetDocumentByKey与GetEntryByKey可能还察觉不出來，当您使用GetAllDocumentsByKey与GetAllEntriesByKey來传回上百笔的资料，相信您就可以察觉到Server Loading的不同了。
十三、资料夹
既然谈到视界，就不得不來谈资料夹。这裡的资料夹当然不是指Windows的资料夹，Louis要說的是Notes的设计组件之一的那个资料夹。资料夹跟视界非常之像，我们可以說它们是龍凤胎也不为过，因为最明显的差别在于”视界选择”。ㄜ..没有「视界选择」那怎筛选文件啊！？既然没有「视界选择」当然就是有其它的方法可以筛选啰。资料夹筛选文件的方式可以透过程序或使用者手动筛选（复制或剪下，然后贴上）。换句话說，资料夹内的文件主要是由程序或使用者手动置入的。
资料夹应用的最彻底的当属邮件资料库了，收件匣各位应该很熟悉吧，它老兄就是资料夹而不是视界，从R5的邮件资料库可能还看不太出來哪些是资料夹，哪些是视界，但从R6的邮件资料库就比较容易分辨了，因为它多了一个「视界」的展开项目，在裡面的全部都是视界。不过在「视界」的展开项目以外还是有视界的。若要真正去辨别的话，还是要从Notes Designer比较明确一点。
先来解释「手动」放文件到数据夹的观念吧。假设A视界与B视界的视界选择条件一样，其所筛选出來的文件其实都是同一份文件。但是，当您在C资料夹与D资料夹中各看到一份几乎是一模一样的文件，在资料库中它们『可能』不是同一份文件，而是兩份文件，原因在于资料夹是独立的个体，所以手动个别贴上的话就会是两份文件。简单來說，资料夹的文件是被「放」进去的，视界的文件是被「筛选」出來的。这样您应该就懂了吧，再不懂，那就请您去邮件资料库多玩几次复制或剪下，然后到处贴上的游戏啰。好吧，再鸡婆举例說明一下：
1.当您从A视界中复制一份文件，然后贴到C资料夹，此时C资料夹有一份文件，D资料夹会是空的，A视界则变成兩份文件。
2.再到D资料夹贴上那份文件，这时C资料夹还是只有一份文件，D资料夹当然也只有一份文件。但是，回过头來看原來的A视界，您会发现A视界中会变成三份文件。
3.这三份文件=原來的文件＋C资料夹的文件＋D资料夹的文件。其实从文件属性中可以看到这三份文件的UNID其实是通通不一样的。
以上都是手动放文件到数据夹的观念，接下来就是「程序」放文件到数据夹的观念了，使用NotesDocumentCollection.PutAllInFolder将文件放到数据夹中时，文件并没有增加，因为PutAllInFolder并不是「复制->贴上」文件，而是帮助数据夹「筛选」出符合条件的文件再「显示」出来。所以来源视界与数据库中的文件是不会增加的。
资料夹有一个很好用的功能－排序。当您使用GetAllDocumentsByKey从视界取得某些文件时（NotesDocumentCollection），这些文件并不会按照原视界的排序一份份排好，所以如果当您的需求是要「依照某种顺序」來处理这些文件的话，您可以先建立一个资料夹，并将此资料夹的排序设定成您想要的，再用PutAllInFolder方法把文件通通「显示」到里面进去，这样您的文件就会照顺序排了。不过请记得，处理完请务必记得再使用RemoveAllFromFolder把那些文件从资料夹删除。否则这资料夹中的文件会一直增加，这样就会造成之后所处理的文件不是当次放进去的文件，而是累积已久杂七杂八的文件。
十四、随处可得的文件
这一篇是要响应某位匿名朋友的问题－何谓前端文件、后端文件、屏幕上看到的文件、内存中的文件、数据库中的文件？其实在前面几篇中，已经有谈到文件的观念，不过没有以这几个项目来做区分说明就是了，所以这部份我们就当作再次温习文件的观念吧!!再者，路哥认为这问题以一位初学朋友而言问得实在是很不错。而这问题我相信也是众多初学者的问题!!
1.后端文件
后端文件的产生基本上可以分成两种－透过套表产生与透过程序产生。前者当然是由使用者开启套表，并在相关字段输入数据后「储存」产生的。后者则是透过Lotus Script或Java产生的，例如Set doc = New NotesDocument(NotesDatabase)……Calldoc.Save(True,True)。您看看，这两者都有「储存」的程序喔，如果没有储存的程序，文件就不会在数据库中产生。当文件进入到数据库中时，我们就可以称它们为后端文件了。而在Lotus Script中是以NotesDocument类别来实现的。
所以，只要是已经经过储存的文件，我们就可以统称为数据库中的文件。
2.前端文件
至于前端文件就很简单了，不管是新文件或是原本就已存在于数据库中的文件，只要是透过套表呈现到屏幕上的就都叫做前端文件。所以其实屏幕上看到的文件就等于前端文件，其主要的作用在与使用者达到互动。在Lotus Script中则是以NotesUIDocument类别来实现的。
3.后端文件与前端文件的关系
同一份文件会不会同时拥有前端文件跟后端文件呢？答案是「不一定」。
在前面的随笔中有提过，利用套表开启一份新文件时（也就是前端文件），打开文件属性方块后是看不到什么较实际的信息的，因为还没经过储存程序，也就是说未储存的新文件就只有前端文件。
但用套表开启一份已存在于数据库中的文件时，在屏幕上看到的就是前端文件，您在上面修修改改尚未储存的数据均可视为前端文件的部分。但此时开启文件属性方块，您可以看到此文件的相关属性与各字段数据，这部份则是属于已储存之后端文件的部份。若您在此时按下储存，前端文件的数据就会更新到后端文件中了。这就是前端文件与后端文件并存状况。
至于在Lotus Script中怎么透过前端文件来取得后端文件呢？只要使用NotesUIDocument.Document即可，因为NotesUIDocument代表目前开启的前端文件，而Document则是指目前文件的后端文件。
4.内存中的文件
这部份麻，我想就跟Lotus Script或Java程序设计有关了，我尽量解释您就尽量看看，能吸收多少算多少。
在LotusScript中有NotesDocument与NotesDocumentsCollection的物件。当您使用GetDocumentByKey方法取得NotesDocument对象，或是使用GetAllDocumentsByKey取得NotesDocumentsCollection的对象时，被取得之文件对象所包含的所有数据都会被储存在内存中，等待您进一步的处理。
在前面路哥也提到过，若文件中有很多数据，则太多的文件就会造成内存的负担，所以，如果您只是很单纯的处理少数资料，就请尽量使用NotesViewEntry或NotesViewEntries，因为内存只会储存文件在此视界的直栏数据，而不会储存文件的所有数据。
5.结论
文件是很抽象的观念，我稍微将它具体化一下，但并非一模一样。数据库就类似公文柜，视界就有点像是公文夹，文件类似现实生活中的公文。如果没有公文夹视界来将文件分门别类的保存起来，数据库就会像是一个摆放了一大堆杂乱无章文件的公文柜。
我建议您可以再回到前面几篇温习一下，相信会有不同的感觉的。
十五、选择开启文件的套表
回到咱们的进度上吧，在本篇随笔中，这一节算是唯一在进度上的一节。路哥好像没有谈到有进度吧，因为进度在路哥的脑袋瓜子里，呵呵。
相信各位在看过前三篇随笔后，对文件跟套表的关系应该有一定程度的了解，所以接下来要为各位介绍的是，当您开启一份文件时Notes是如何决定要用哪一张套表来显示文件。
不懂路哥在说什么吗？没关系，我就再稍微解释一下，Notes文件并非只能使用当初建立此文件的套表来开启，也就是说一份文件可以使用不同的套表来开启，而产生的结果就是在前端呈现的文件之排版与数据会不同。例如，有A与B两张套表，A套表有两个字段－AAA、BBB；B套表只有BBB字段。另外在数据库中有一份文件储存了AAA字段值111与BBB字段值222。这时使用A套表开启甲文件时，您会看到屏幕上显示111与222两个字段值。接下来再用B套表开启甲文件，此时您就只会看到222而已。也就是说同一份文件会因为套表上的排版与字段不同而有不同的显示。
用最最最简单的实际例子来说明好了，假设路哥有两条牛仔裤，A牛仔裤的左边裤管剪了一个洞，而B牛仔裤则是在右边裤管剪了一个洞，当路哥穿A牛仔裤时就会露出左膝盖，穿B牛仔裤时则是露出右膝盖。即使你们会因为我穿不同的牛仔裤而看到不同的膝盖，但其实路哥本身还是有两个膝盖，并不会因为穿哪件牛仔裤而真的少了哪个膝盖。不过……路妈要是看到我穿这种牛仔裤，一定又会念说，你是没钱可以买裤子喔!! ><
好回到正题，Notes是如何决定要用哪张套表来开启文件的。采用顺序为，套表与文件合并储存à视界的套表公式à Form字段值à数据库的预设套表。说明如下：
1.套表与文件合并储存：这在随笔2中的第3页的倒数第三段有解说过，请自行回头参考。
2.视界的套表公式：这个就要特别解释了，因为曾经有两位从软件公司出身的朋友同时问过我一个问题就是，如何在视界中依不同的条件来选择不同套表开启文件。其实满惊讶的，因为我觉得这是非常基础的功能，而且是必须知道的。所以在此特别说明，答案是视界的套表公式，在哪儿呢？就在写视界选择公式下面的那个「套表公式」。
简单来说，您可以写一行程序，假设A字段值=1时就用A套表开启，否则就用B套表开启。所以当A字段值有所变动时就会使用不同的套表来开启文件。个人觉得这功能虽然很少用，但是，却是很好用的功能。
3.Form字段值：在Notes中有个保留字段叫做Form，而此字段值就是在储存用来开启文件之套表的名称，所以强烈建议使用Lotus Script建立新文件时都要指定此字段值（语法：doc.Form=”套表名称”）。
4.数据库的预设套表：在套表的设计属性的基础卷标下有一个「预设的数据库套表」选项，若勾选此选项后，前面所说的条件若都不成立时，就会采用勾选此选项的套表来开启文件。我想应该会有朋友问说，那要是有两张套表都有勾怎办？那您就勾勾看吧，呵呵。一个数据库只能存在一张预设套表，所以后勾的赢，也就是说若A套表勾了以后，B套表又勾，那系统就会自动取消A套表的该选项。
好，讲到这边整理一下，当您开启一份文件时，Notes会先参照文件当初储存时的那张套表是否有勾选「套表与文件合并储存」属性，若有则采用该套表开启。若没有就会参照视界的套表公式，所以若您有写套表公式时就会依照该公式的条件来开启文件。若没有写套表公式，那就会参照文件中的Form字段值，若文件中此字段值有指定套表名称，就会使用该套表来开启。若没有则会参照最后的防线－「数据库的预设套表」。若数据库中没有预设套表呢？如果路哥没有记错，系统好像会出现「找不到套表」之类的错误讯息。不过也有可能记错喔，最近脑筋不太灵光…呵呵。
十六、Lotus Script超基础观念
这是路哥突发奇想的主题，相信初学者的您在看完此节以后，一定会非常有收获唷!!
LotusScript是以对象为基础的程序语言，还谈不上是完全对象导向的语言。市面上有很多书籍在谈对象导向，好像一开始都是用车子或飞机来当例子，可是路哥总觉得缺少了什么。所以长久以来路哥一直很想找出某种生活上的实际情形来与LotusScript中的类别对象相对照，让初学者有很清楚的概念。在某天明月高挂的夜晚，终于让路哥顿悟了，就只差没成仙而已。因为是新的想法，所以各位这次就当作是路哥的白老鼠吧，感恩不尽，若有讲错的地方还多多海函 Orz。
在开始之前，路哥先声明不把所有的类别都拿出来讲，我只用了几个比较常用的类别，其余的就交给各位自行体会了。让我们开始吧!!
Lotus Script的特点之一，就是有很明确的对象阶层，而且大部份每一阶层对象皆会包含下一阶层对象（NotesItem是最底层对象，所以只有方法与属性）。
例如NotesSessionà NotesDatabaseà NotesViewàNotesDocumentà NotesItem。
精采的来了，我的虚拟实景是：
1.NotesSession = 地球，因为地球是一个大环境，包容各式各样的对象与数据。
2.NotesDatabase = 台湾，因为每个国家就像是一个数据库，有很多的文件跟视界存在。
3.NotesView = 县市行政区，每个县市可以视为一个view都是以现式的名称来将位于各地的房子筛选出来，所以NotesDocument=房子，如下说明。
4.NotesDocument = 房子，因为房子有很多数据，像是地址就可以比做是UNID，因为地址绝对不会重复。
5.NotesItem = 房子的基本数据，透过GetFirstItem就可以得到类似房子有几坪、户口数、在第几层…等等的信息。
所以呢，现在如果我们想要知道路哥房子的房间数，程序可以这样写：
Dim 地球 As New NotesSession
Dim 台湾 As NotesDatabase
Dim 台北县 As NotesView
Dim 路哥的房子 As NotesDocument
Dim 房间数 As NotesItem
Set 台湾 = 地球.CurrentDatabase
‘ 因为我们现在在台湾，所以就用CurrentDatabase
Set 台北县 = 台湾.GetView(“台北县”)
‘ 假设台北县这个View是以户长姓名为第一直栏而且有排序
Set 路哥的房子 = 台北县.GetDocumentByKey(“路哥”)
‘ 既然是要找路哥的房子，当然Key值就是”路哥”啰
Set 房间数 = 路哥的房子.GetItem(“房间数”)
‘ 因为要查路哥房子的房间数，所以就直接去找房间数这个字段，此时传回值会
是3，因为路哥的房子是三房两厅。
举一反三，如果要找路爸的房子呢（不是路霸喔，是路哥的老爹啦…哈哈），那就把Key值改成”路爸”，因为路爸也住台北县啰，这样就可以找到路爸的房子数据了。
如何，够清楚吧，为什么路哥会想用这种方式解释，是因为这样比较能够感觉出Notes是文件式数据库的感觉，至于市面上那些使用飞机、车子当作例子的书籍，我想作者们应该是为了表达对象导向的观念吧。
扫一扫
854
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
