81. Domino视图Web展现技术胪列

以列表形式显示大量数据是各种开发中最常见和基本的需求之一。在数据保存在关系型数据库的Web开发中，程序员要处理的是分开的两项任务，一是从数据库中查询记录，二是在视图层生成显示这些数据的HTML。如何分页是主要问题。Domino以界面为导向的开发风格和不适于动态查询的文档型数据库使得程序员面临完全不同的处境和问题。预先设计的视图不仅定义了包含的文档，也设置了外观属性，集数据层和外观层的功能于一体。在客户机中，视图拥有和设计时同样的外观，无需编程。在Web端，因为Domino默认生成的视图HTML过于简陋，程序员还是需要各种各样的方法改进其外观和操作性。下面就胪列了我曾经接触和使用过的Domino视图Web展现技术，并做了简单分析和评价。

1.       使用Domino生成的HTML

优点：

• 无需编程。

缺点：

• 显示原始简陋。

2.       使用Applet

优点：

• 无需编程。
• 操作与客户端一致。

缺点：

Applet的所有缺点，包括：

• 用户所在机器需安装Java运行时，虽然目前大部分机器都已安装。
• 需要下载和载入Applet，速度较慢。
• 与网页整体风格不一致。
• IBM早已放弃其更新，实际上自Java7 Update 51起因为没有提供Java运行时要求的权限属性（Permission Attribute）Domino自带的Applet都无法在浏览器里运行。

 3.       将视图内容显示为HTML

这种方法需要在视图的列公式内计算产生最终的HTML。

优点：

• 可以精细地自定义显示的内容。

缺点：

• 笨拙繁琐，难以维护。
• 该视图只能用于Web显示，无法通用于客户端显示和后台查询。
• 列中的大量HTML计算，对视图索引的速度和大小都有负面影响。

4.       在视图原始HTML载入后用JavaScript调整修饰

Domino早期Web开发中常使用的方法，在显示视图的页面的onload事件里运行一段脚本，修改视图原始的HTML。Domino产生的视图HTML原始、丑陋、古怪且总不改进，使用这种方法需要透彻了解这些HTML的细节。

优点：

• 能够完全自定义视图的展示，将其修改成任何所需的外观。
• 脚本写得足够灵活的话，还能配合代理获取视图的外观属性以设置列宽度、标题等，无需手工输入参数。

缺点：

• 需要JavaScript开发（可写成适用于所有视图的通用函数，只需一次开发），并且对HTML的修改无逻辑可理解，只能根据Domino生成的HTML硬编码。例如下面的片段：

//1、删除标题行最后一个单元格
//strDiv = strDiv.replace(/<\/TH><\/TR>/g,"");
//2、删除分类行最后一个单元格
//strDiv = strDiv.replace(/<\/TD><\/TR>/g,"");
//3、删除各内容行最后一个单元格
//strDiv = strDiv.replace(/<\/TD><\/TR>/g,"");

代码难于理解和维护。

• 一旦Domino修改视图生成的HTML，就需要重新观察并相应调整代码。
• 页面载入时可能会先显示原始视图，经过脚本运行的延时后才显示调整后的视图。

5.       使用JavaScript读取视图内容的XML或JSON

这种思路是Domino视图Web展示上的一大突破，在readviewentriesURL命令下Domino服务器发送到浏览器的只有视图的内容数据，不包含字体、颜色等任何外观信息，读取它以生成显示视图的HTML完全依赖JavaScript脚本和CSS。这些前端文件构成独立的视图层，因而具有前所未有的最大的灵活性。在XPages出现之前，这种方法已经为许多公司和开源代码所使用。

优点：

• 具备第四种方法的所有优点，而没有它大部分缺点。
• 能在一个页面上加载多个视图。

缺点：

• 需要JavaScript开发，要掌握相关的XML知识和理解readviewentries产生的数据格式。

6.       使用XSLT技术转换视图的XML数据

我在接触到上一种方法后想到，既然可以获得视图的XML数据，那应该也能用XML技术家族内的XSLT来将此XML转换成用于显示的HTML。下面就是我当时的试验代码和显示效果：

  
View XSLT
    
	  
		
	  
	  
		
	  
	  
  	  	
		
			
			

		
Number
Who
Date
Time
Size
Subject
      

        

		

		

		

		

	  
	  

		
		

		
	  
      
    

大家可能会注意到，上图中的日期和时间列没有解析原始的日期时间字符串。这是因为在我试验时的XSLT 1.0标准中，既没有方便的日期格式化的函数，也不能自定义函数。现在XSLT已经升级的2.0，上述两方面都有改善。但是与用JavaScript相比，使用XSLT来生成HTML受制于XML风格的语法的繁琐，更重要的是没有良好的报错和调试机制，稍有差池，页面只会显示一片空白，很难找到错误根源。

优点：

• 能够完全自定义视图的展示，将其修改成任何所需的外观。

缺点：

• 需要XSLT编程，语法繁琐，难以调试。
• 无法做到像采用JavaScript的方案那样灵活，例如动态地从服务器获取视图的外观数据。

7.      XPages中的视图控件

XPages终于将Domino的Web开发带进现代。Web上的视图显示也做到了和客户端一样在设计时所见既所得，视图控件默认生成的显示简洁美观。缘于JSF架构，Domino传送给服务器的是视图控件render生成的HTML，而非前两种方法的XML。视图控件中的分页器（pager）的partialRefresh属性决定翻页时是整页刷新，还是部分刷新（即采用Ajax）。

优点：

• 无需编程。
• 在设计时方便调整外观。
• 一个视图可以用多个视图控件以不同方式展现，节省了后台视图数量，提高了数据库性能。
• 一个页面可以显示多个视图。

PS，数年前一同事向我推荐一个OpenNTF上的项目xGrid，用jqGrid来显示视图的XPages自定义控件。看上去功能繁多，细究却有问题。jqGrid是一个jQuery插件，在网上应用挺多，甚至还专门出了一本书。但是我看有过度工程之嫌，分页、分类、排序、搜索、调整列、导入导出数据、行內编辑……作者想把表格数据显示界面涉及到的所有功能都集中到一个JavaScript插件里，用力过猛。分页、排序、搜索这些功能都应由服务器端处理数据，前端脚本只能发挥触发和显示的作用，即使前端插件的功能无所不包，没有服务器端可调用的接口也只是摆设，而服务器端这些操作数据的逻辑依赖于编程语言、数据库、数据设计和业务需求各有不同，让它们都来适应一个前端插件的接口，有些本末倒置，削足适履。jqGrid插件为了涵盖繁多功能和各种服务器端技术，实现最大程度的灵活，必需大量的配置，要学习这样一个万能而臃肿的插件如何使用，也不是一件小事了。

以上还只是jqGrid插件的问题，xGrid的缺陷更是致命的。jqGrid对表格里显示的数据，通常是需要时（如翻页）才从服务器读取，搜索也是将请求发送到服务器，但是它也可以一次载入所有数据，以后所有的功能都由JavaScript操作这些本地数据。这当然是被设计成展现少量静态数据时的用法，但是xGrid竟然只能一次性读取所有数据（loadOnce属性只能设置true），除非是文档数量很少的配置视图，对任何正常大小的视图，一打开就下载所有数据既是对服务器和带宽的考验，也是毫无必要的浪费。后来的分类、排序、搜索种种操作，虽然看上去华丽，但在数据量大的情况下，性能必然低下——JavaScript本就不是设计用来在浏览器内处理大量数据的。更滑稽的是，当时我在一个中文Lotus技术论坛里看到讨论这个插件的文章，挑战速度极限一次性下载五万条文档的数据。我不禁想，这是在探索Domino视图展示的新技术，还是在做让Domino服务器宕机的极限测验，就算服务器没被折磨死，视图打开后，随便转到另外一个页面这五万条文档的数据就白下载了，再打开那个视图，又要折磨服务器和网络一遍。

提上面这个插曲，是想说明，视图的展示要兼顾前端的美观和后台的性能，还要考虑程序员实现和维护起来方便，突出一点而偏废其他都不是好的架构。