posts - 156, comments - 211, trackbacks - 0, articles - 6

2006年2月22日

    web开发这个领域是很有意思的。首先,web的兴起是在软件业发展到一定阶段才发生的,它必然吸收了软件业最优良的思想,必然有其本质上先进的地方。另 一方面,web的应用毕竟是时日较短的事情,造成很多基础架构方面也是薄弱的,原始的。
    具体来说,前台html的展现模型本身是非常先进的。xhtml+css+js实现了结构(structure), 表现(presentation)和行为(behavior)的分离。xhtml本身是简单的文本文件,通过工具的支持可以做到结构上的"所见即所得" (WYSIWYG)。 在js中操纵html结构具有多种方式:可以通过id直接访问html片断,可以直接操纵dom的层次结构,可以将html作为线性文本处理,可以应用 xml相关的技术对dom结构进行变换,可以动态切换html元素的css风格等。dom结构的访问方式是高度统一的,通过parentNode, childNodes, setAttribute, getAttribute等少数几个 API函数,我们可以通过一种简洁一致的方式操纵所有的节点和相关属性(当然,IE这方面的bug不少)。html相关技术中所显示的结构控制能力远远超 越了传统桌面程序中组件技术所能达到的程度。
    但另一方面,html也是原始的,缺乏现代应用程序所必需的标准控件,典型的如Tree控件和Tab控件等。每个开发商都不得不实现并维护自己的界面库。 通过web界面调用后台业务逻辑的方式更是很粗糙的。基础的servlet只提供了基于IO的有限状态机模型,对于后台功能缺乏有效的组织,而对于前台界 面也缺乏合适的抽象手段,仅仅作为文本输出。MVC框架建筑在servlet模型之上,将后台逻辑功能以一种统一的组织方式向外暴露。而tag技术在前台 界面中的应用,使得我们可以有效的识别并分离出我们所关心的结构。这些技术的发展都是web开发模型逐渐精细化的必然结果。
    为了在服务器端获得足够强的结构控制能力,有些人求助于桌面程序的历史开发经验,希望通过java语言中的结构表达能力来扩展web开发的模型,于是便有 了echo2, tapestry这样的组件化web开发框架。坦率的说,我并不看好这类强类型建模的框架。除了性能上的原因之外,我反对这类框架的一个主要原因是 java语言直接表达的结构一般无法达到用xml文本表达的结构的统一性和灵活性,从而很难应对界面的快速变化。实际上,对web界面进行组件化的分解并 不一定需要一种强类型语言支持的组件模型。通过自定义标签的使用,我们完全可以实现将页面分解为多个子部分的目的,这一点已经由witrix平台中的 tpl模板技术所证实。

    web开发是个既先进又落后的领域。很多人面对这种矛盾的情况,难免思想上会出现混乱。关键是要认清技术的本质而不要被OO是否必需等抽象的讨论所迷惑。

posted @ 2006-02-22 20:39 canonical 阅读(1547) | 评论 (1)编辑 收藏

web程序需要完成  html <--> java 之间的映射,在界面越来越复杂,越来越多变的今天,这项工作也变得越来越困难。按照级列设计理论的观点,我们应该去寻求一些中间的过渡步骤。在 witrix平台中,tpl模板引擎正扮演了这种中间角色。通过tpl模板我们实现了如下映射路径

html <--> tpl <--> java

注 意到这里html与tpl之间,以及tpl与java之间的映射都不是trivial的同构关系,而是都可能存在着复杂的运算过程,从而实现了html与 java映射过程中复杂性的分解与均摊。tpl与java之间的关联主要通过EL(expression language)表达式来完成,而html与tpl的映射则主要通过自定义标签(tag)机制。
注意到tpl所提供的中间层具有独立的重大意 义,它并不是臆造的或者是简单的技术驱动的结果。实际上,在web开发中除了java结构与html结构之外还存在着第三种结构,即用户眼中的界面结构, 本来它与html所描述的结构是简单的一一对应的,但是随着界面技术的发展,html的描述能力逐渐被耗尽,成为了internet时代的"汇编语言"。 现在一个简单的页面片断就可能对应着大量html代码,因而丧失了"所写即所见"的简单性。tpl通过强大的抽象能力在某种程度上恢复了程序员对于界面表 现结构的直观控制能力,并在一定程度上保留了html所见即所得的特性。

在witrix平台中因为存在着tpl这一强大的抽象层,使得我们对于ajax的支持可以采取更加灵活的方式。
ajax(Asynchronous JavaScript + XML)的标准结构是
html <--> js <==> xml <==> java

在 这种结构中通过xml信道的只是数据,而界面的表达逻辑与展现逻辑完全由js来控制。这种结构发展的一个极端是所有的界面展现结构都由 javascript动态构造出来,而完全丧失了html静态描述的特点,丧失了所见即所得的设计。与直接实现html<-->java之间 的映射情况类似,直接实现 html <--> js之间的映射也是困难的,尽管dom模型的支持可能使得js映射的难度要低于java映射。

在witrix平台中ajax的方案为
html <--> js <==> tpl <--> java

即tpl取代了ajax标准方案中xml的位置,使得映射过程的复杂性得以分散化。

结合jsplet框架的拉模式(pull mode),我们定义了如下ajax访问接口
js.ajax.load({request='objectName=/@Test&objectEvent=query',tpl:'/test.tpl:partA',targetId:'testDiv'});

1。 远程服务请求就是一段普通的http post request, 避免了额外的xml编码解码需求。
2。请求到的数据先由tpl文件来进行处理。注意到这里tpl文件的url分成两部分,前一部分是tpl文件的虚拟路径,而 :后面的部分,即partA指出请求的是该tpl文件内的partA部分,而不是整个tpl文件。
3。返回的html结果被填充到targetId所指定的html元素中。

test.tpl文件的内容
<html>
<body>

<tpl:define id="partA">
<img tpl:tag="ui:EditTable" />
</tpl:define>

<div id="testDiv">
<img tpl:tag="ui:ViewTable" />
</div>

</body>
</html>

tpl具有强大的结构构造能力,在这里我们以非常小的代价实现了tpl片断的定义,例如test.tpl中的partA部分。这里通过id访问tpl片断就如同js中通过id来访问html片断一样。
最后提一个很重要的思想:大量零碎的代码片断需要集中存放,否则人的精力会被耗散。一个反例就是struts中的action, 明明只干那么点事,偏偏要占据一个单独的java文件,占据大量单独的配置条目,最终给程序员带来很大的困扰。

posted @ 2006-02-22 20:36 canonical 阅读(259) | 评论 (0)编辑 收藏

Ajax: A New Approach to Web Applications http://www.adaptivepath.com/publications/essays/archives/000385.php
Ajax(Asynchronous JavaScript + XML)并不是一个革命性的崭新概念(也许根本就不存在突发的革命),它的技术基础在多年之前就已经牢固的建立起来了,在概念层次上的探讨也早就不是一个 新鲜的话题,只是大规模的有深度的应用似乎是最近才开始的。
从广义上说,web应用至少涉及到两个结构,
1. 后台以java语言表达的业务逻辑结构
2。前台以html语言表达的界面表现结构。

web开发很大一部分工作就是建立这两个结构之间的关系。即我们需要
html <--> java

我 们首先要意识到这两种结构之间并不一定是同构的,即后台数据的组织方式与前台展现时的结构是不同的。同样的数据可以对应于不同的展现结构。这也是所谓 MVC架构实现模型与视图分离的依据。传统上,基于Model2模式的MVC框架中,这两种结构的映射只能在很粗的粒度上进行(即整个页面的粒度上),因 此妨碍了封装和重用。为了进行细粒度的映射,我们必须要拥有细粒度的结构控制能力。而目前最强的结构控制能力存在于javascript/DHTML模型 之中,在js中html的结构可以是一段线性的文本(innerHTML和outerHTML), 可以是层级组织的节点(parentNode, childNodes), 也可以是按照key组织起来的Map(getElementById)。在不同的情形下,我们可以根据需要选择不同的结构模型。
ajax体系很直接的一个想法就是将所有关于界面表达和控制的结构都推到前台,由控制力最强的js来控制后台数据模型与前台html模型之间的映射。
html <--> js <==> xml <==> java
在ajax 体系中,xml所扮演的角色是js与java之间的翻译通道,它将js中的结构与java中的结构对应起来,这种翻译比html/java之间的映射要简 单的多。其实它甚至可以是一种同构的映射,可以用一种通用的方式来进行,例如结合burlap与buffalo包的功能。结合webservice的一些 思想,js/java之间的映射是可以在函数调用这种细粒度上自动进行的,从而我们最终可以在概念上完成html/java之间的细粒度映射。

posted @ 2006-02-22 20:33 canonical 阅读(925) | 评论 (0)编辑 收藏

    AOSD(Aspect-Oriented Software Development)可以看作是AOP技术思想在设计领域的一种投射. 采用Aspect的观念之后, 我们在系统分析时应用如下的分解策略
     base + extensionA + extensionB +... 而不仅仅是 partA + partB + ...
  这种分解的基本理由在于base/extension的依赖关系与extension之间的依赖关系并不相同. 在理想情况下, extension之间是完全正交的, 而它们通过base可以构成一个整体, 这是一种典型的star schema. 但是在实际的软件构造过程中, 软件各个元素之间的交互方式要复杂的多:
 1. extension之间可能存在着相互作用, 最简单的一种情况是extension执行时的序关系(order).
 2. 一个结构上的extension可能分散到多个component上, 如何精确而有效的控制定位是一个非常困难的问题.
    就目前的AOP技术而言, 对于extension的控制其实是非常乏力的(但这并不意味着AOP必然放弃对extension的控制), 我们尚需要积累更多的经验. 在实做中, 更加稳健的方法往往是应用aspect的思想而采用传统的实现方式.
    AOSD在理论上存在一些价值, 例如它为use case的extension符号找到了技术对应, 因而使得这个概念变得更加明晰, 而在传统中, 对于use case的extension的解释一直是模糊而混乱的. 目前在真正的开发中, AOSD所描绘的全程建模仍然只是一个遥远的梦想.

posted @ 2006-02-22 20:28 canonical 阅读(728) | 评论 (0)编辑 收藏