API必须要提供充分的功能，以供调用者完成自己的任务。

API应该是最精简的，不要为调用者带来多余的不便。

如果没有理解API的使用环境的话，那也就不能去设计它。

通用性的API应当是与具体使用场景无关的，而特定用途的API则要充分考虑使用策略。

API应该从调用者的角度来进行设计。

好的API绝不推卸责任，把自己该做的事情留给别人。

在实现API之前，就应该把API文档化。

好的API应当符合工效学（Ergonomic）。 

In general , IE will cache the images which they have been downloaded. But, i found a issue that IE is repeatly downloading images that i add them to page via javascript. it is a real performance ploblem, because of have no time to pay attention to this issue at that time , i ignored it. today, via the google, i find the answer for it, which is a bug of IE.

快速开发，象VB/Delphi桌面开发一样开发Web应用                                      

这一点，显然microsoft走在了前面。借助成熟并且强大的IDE，ASP.net使得Web开发能够象开发桌面应用一样的容易，也大大提高了生产效率以及有效降低了Bug缺陷率。分析ASP.net的特点，以及结合这几年Web开发的趋势，我们可以得出一个结论，基于UI控件的开发将会是下一个发展方向。开发人员仅需要通过对控件的定制即可完成UI层的开发是多年来java开发人员的梦想。

无奈的是，j2ee的Web层开发被Struts，Webwork等老牌MVC框架统治了多年，我们经常抱怨这个那个的问题，但也没有勇气去尝试并替换新的技术，只能默默承受。这一切都造成了生产力的瓶颈。Ajax技术在近几年呈现出后来居上的态势。Ajax技术提倡给用户更好的操作体验，将B/S系统开发的像C/S那样。从表面看，Ajax倡导的是提升用户体验，但背后孕育的思想是非常的有价值。Ajax更强调客户端的计算能力，在客户端严格区分界面，操作，以及数据。这分别通过使用HTML/CSS，javascript，XML/Json来实现。客户端的UI控件也大放异彩，经过一些封装，对于实现一些浏览器特效也变的非常的容易。

与此同时，服务端的框架也在不断的发展。JSF，Taperstry等基于组件的技术也在不断发展。

 

服务端组件还是客户端组件

既然我们认定基于组件的Web开发会是以后的主流，那么采用服务端组件还是客户端组件是一个关键，这将直接决定Web层的架构设计和技术方案。我们来分析一下二者的优缺点。

先来看一下客户端组件的优势和劣势

优势:

1.         纯粹的javascript控件，在客户端能够创造出强大的特效，可以明显提升用户体验

2.         通过javascript控件提供的接口，可以屏蔽低层的js/dom操作，使开发人员只需要具备少量的js技巧就可以

3.         在客户端将数据和控件绑定能够完美的分离数据和显示

4.         在客户端维护数据／对象的状态，可以解决很多以前很难解决的问题（例如，未修改数据提交是否要从数据库加载数据的问题）

5.         减少对于网络带宽的要求。通常情况下，服务端传递到客户端的只是实例数据和页面控件的元数据，而不需要输出HTML的信息

       劣势:

1.         性能。如果满屏的控件都是由javascript产生的，那对于客户端机器的性能则有更高的要求。对于一个产品，需要非常关注这个指标，毕竟我们不能要求所有的客户机都升级

2.         缺乏一致的组件模型。在网上随便找一个第三方js控件实在太容易了，一家比一家做的好。但正因为JS太灵活了，所以，每个开发人员开发的控件都自成体系，虽然可以通过种种方式整合，但这种缺乏一致的组件模型，会对以后升级，维护以及扩展带来很大的影响。所以，通常来说，如果采用的是客户端组件，我们会自己编写一些关键的JS控件，再寻找其他第三方控件加以整合

3.         Javascript虽然可以模拟OO的特性，但毕竟是脚本语言，并没有成熟的OO理论做为基石，这对于扩展和维护带来了困难。这与第２条类似

4.         权限控制。如果纯粹在客户端生成控件，对细粒度的权限控制非常麻烦。解决方案可以通过另加远程调用获取权限控制信息或者干脆在初始化页面时就将权限元信息传递到客户端，总之，在客户端做这件事情非常的麻烦

5.         源代码安全问题。由于js源码是完全暴露在客户端的，所以客户端很容易就可以取得生成控件的源码，虽然可以通过一些混淆机制来使客户端无法阅读代码，但混淆也有很多限制。这对商业系统非常的不利

6.         多浏览器问题。虽然组件化是有效解决这一问题的有效途径，但其实要写出跨浏览器的控件是一件多么困难的事情

 

服务端组件通常基于Template或者封装生成HTML的细节。来看一下服务端组件的优势和劣势

优势

1.         有成熟的OO理论为基础，我们可以写出很多面象对象的UI控件，以及建立控件之间的关系

2.         丰富的组件。现有的基于组件的框架提供了大量的服务端控件，例如JSF，Taperstry，Wicket，etc…

3.         这些组件框架往往有自己的组件模型，扩展，测试以及维护都很方便

4.         性能。在服务端生成组件，能最大限度的利于服务器的能量，减轻客户机的压力

5.         权限控制。对控件权限控制非常适合在服务端做，我们只要在生成控件前，先调用一个CheckPermission方法就可以了

6.         不存在源代码泄露的问题

缺点

1.         在展现效果上显然离javascript控件还有很大差距

2.         在客户端没有控件模型和访问接口，使得开发人员还要编写大量的脚本，并且很难保证UI调整/升级时这些脚本不出错

3.         客户端没有完备的控件模型，使得保存复杂的状态信息变的非常困难

 

综上所述，服务端和客户端各有优缺点。对于产品级别的Web开发，我的观点是，在架构上我们需要同时具备这二者。在控件生成上，我更倾向于在服务端完成，在生成服务端控件的同时，需要同时生成客户端控件模型，并输出到客户端。这个客户端模型也许不需要同服务端模型一样完备，但它必须具备封装客户端脚本访问控件的细节，提供完备的访问和数据处理的接口。

 

要达到快速开发，还要解决一个配置文件的问题。Struts，Webwork等框架一大诟病就是为了维护JSP和Action的关系需要编写和维护一大堆配置文件。稍微一不留神，就会影响了整个系统的运行。为减少此类配置问题，我们可以引入

1.         Annotation

2.         基于规则

提供强大的功能，具备高度的可定制性，而无须修改代码

思考一下我们目前使用Web Framework – Struts，它真正给我们带来了什么强大的功能吗？仔细想想，其实我们能真正利于的除了那个半调子的MVC模型外（Struts等传统的Web框架受限于浏览器模型，并非经典的MVC），其他都没有太多的价值，况且成堆的配置文件问题还一直未能很好解决（这个前面已经提到了），并且基于Struts上的框架其实并没有有效解决很多问题，反而给项目组开发带来很多工作量。

我这里举几个例子

URL权限控制

由于B/S应用的特殊性，系统权限的控制一般通过菜单权限+权限标签来解决。

B/S由于访问的入口都是基于URL，所以对于需要对所有的URL都要加以限制。这样，每一个module都要配置很多琐碎的URL。由于还加了module + url的双重控制，目的是为了必须通过唯一的途径到达可访问的URL。这样，如果需要开放模块接口的情况下（就是通过A模块直接访问B模块的某些页面）就要重复在A模块中配置B模块的URL，这是一种很愚蠢的做法，这个问题有待解决。

 

国际化

国际化并不是简单的将中文转换成英文这么简单。不同的国家由于文化地域的差异，对于UI的展现的要求有很大的不同。例如中文是从左到右书写，而很多西亚国家使用的希伯来语则是从左到右书写，这样，在排版上会有很大差异。又例如中文对于地址的描述往往是从大到小，比如中国，上海，长宁。而美国等西方国家则刚好相反。所以，单纯认为将某一种语言替换成另外一种语言这种简单的方式是无法做到系统的国际化的。这个问题有待解决。

 

模块Web接口

Party调用User management模块是这个问题的经典Case。当用户在Party中新建了一个party后，希望立刻为这个用户在系统中创建用户。这时Party需要传递一些信息到用户管理模块，而这些信息只做为显示使用，需要跨越多个页面，但不需要保存在User management模块。并且，当新增完毕用户后，能够返回到Party维护页面。想象一下，如果party是程序的调用者，则User management则是程序的被调用者，它应该开放一个API给Party调用，并且在调用完成后返回给Party是否成功添加的标识。这个问题有待解决。

 

在这里我给出初步的方案。

URL权限控制。基于UI组件模型，我们可以彻底废弃基于URL的访问控制，我们只需要定义每一个module的入口就可以了，正如C/S应用一样，其他的权限控制限制在控件上。

国际化。在提供msg_id的基础上，还要在框架级别支持页面摸版，也就是说在由于国际化导致页面差异很大情况下需要多个不同的页面摸版来解决。比如a._zh_cn.htm，a._en.htm，

系统能够根据不同的语言在不同的摸板之前切换。

模块Web接口。整合PageFlow，PageFlow能够很好的解决这个问题。关于Pageflow，并不是本文所涉及到的，需要另开话题了。

 

所谓高度的可定制性，这则是基于控件的优势，虽然这些框架并没有成熟的元数据模型。但我们需要基于之上建立丰富的元数据模型，以便可以通过工具来定制控件。在做客户化时做到少改甚至不改代码。

 

所以，产品级别的Web开发，框架需要提供更多更强大的功能，并且能够方便整合其他框架。

 

在框架级别定义约束

所谓在框架级别定义约束，就是往框架内加入更多业务元素，业务规则。这些元素，规则都是预定义的，BA/Developer无法修改这些规则，只能从预定义的元素规则中选取。这些规则定义的越多，对开发效率提高的就越多，系统出错率就越低。当然，这也意味着默认情况下，规则所函概的功能就是框架所能完成的功能，这就是局限性。需要在框架功能的内聚/抽象和灵活性之间做出平衡。目前，我们基于数据字典，定义UI字段默认的显示/校验规则，就是非常有效的一种手段。

Web层易测试，易维护

我这里主要指的是UnitTest。Web层的UnitTest是目前我们比较头通的问题。JSP + Struts使我们无法很容易隔离对Servlet context的依赖。做起来相当麻烦。通常的方法是使用一些Mock对象来Mock那些重量级的资源。但经验告诉我们，如果UnitTest的成本过高，就会使PM/Developer放弃UnitTest，而采用其他折中的方式来测试。所以，Web层如果能够在框架级别考虑到易做UnitTest这个因素，会对系统Web层质量提高起到很关键的作用。

 

 

结论

最终在我心中，一个产品级别的Web层开发所依赖的框架就大致有了雏形，它的主要特征是

1.         UI页面的最终产物依托与纯粹的HTML静态页面

2.         基于服务端组件并且在运行时能够自动生成客户端组件模型

3.         基于少量的配置甚至是0配置

4.         无论对菜单/模块权限还是细粒度的功能权限都提供更加方便的支持

5.         在框架级别上支持真正的国际化

6.         能够方便的整合其他第三方框架（服务端和客户端），比如PageFlow

7.         开发框架能够更多的依赖于业务规则

8.         基于POJO，方便UnitTest

   　自打WorldCup开打后，这２０天来鲜有看到比较出彩的技术日志，^_^看来大家都一致为了世界杯冬眠了。

      我支持的德国队终于，终于，没让我失望，虽然场面一度非常的狼狈，不过结果还是我想要的。凭借门将lehmann神勇发挥，点杀阿根廷。正如媒体分析，一旦最后双拖入点球大战，德国的优势将是非常明显。比赛的进程也验证了这点。比赛充满了火药味，这样的比赛的必然会留下让球迷津津乐道的看点

 

 

 

 

 

 

 

 

比赛结束了，一场不算太精彩的比赛，但却足以决定二队的命运，成功就是英雄，失败等待的是球迷的口水。

    在使用Mysql做基础数据库时,由于需要将库B的数据导入库A,而A,B库又包含大量相同的数据,需要使用mysqldump导出脚本.

   通常的命令会是

   1. mysqldump -t 'dbName' > 'scriptName.sql'

   2. mysql -f 'dbName' < 'scriptName.sql'

 

   而使用如下命令导入到A库时不会成功,现象是报出几个Duplicate key error后就完毕了,并未将其余正确的数据插入到A库中.

    捣鼓了好一会,发现在使用mysqldump导出的脚本命令中,insert语句采用是multiline insert synax.而不是采用single insert synax.原来是这个问题. 多行的插入语法在第一个主健重复错误后就不执行后续的对应表的插入语句了.

   于是再加参数 --extended-insert=false,完整的命令是

   mysqldump -t --extended-insert=false dbname > scriptname.sql

   30个日夜的动人心魄，64场较量的悲喜交集，720个小时的跌宕起伏，43200分钟的魂牵梦绕，德国世界杯终于开打啦 ^_^

   昨天晚上揭幕战不想多说，二队奉献了一场精彩的比赛，朝气蓬勃的德国队给人崭新的面貌，Lahm,schweinsteiger等几个年轻人的表现非常出彩。

   对德国足球的忠爱起源于我对德甲的喜欢，虽然德甲一直缺乏所谓的顶尖球星，但联赛崇尚进攻球，整体做战，以及保持均场比赛极高的进球率，再加上世界上最好的硬件设施和专业的转播，使得我感觉周末的球赛就象在过节一样轻松，而不象意甲，让人越来越混混欲睡。

   周围的喜欢德国队的人不多，哎，有太多人对德国队的印象就是身材高大，头球出色，脚下粗糙。呵呵，有太多人追捧巴西，荷兰，英格兰。也许他们忽视了每个球队都会更新换代吧，现在的德国队在不失硬朗打法的基础上，加上很多细活，况且球队非常非常的年轻，我看好他们的未来。 ^_^

   喜欢永远的金色轰炸机kelinsman

 以及沉稳的中场大将Shneider，曾经杨晨在法兰克福的队友

 

      就是在10分钟以前，一个非常好的Idea帮我解决了捆饶已久的大问题，虽然它看上去却是这么的微不足到，但惯以“四两拨千金”也是实质名归。^_^ 现在感觉是不是软件交互模式也应该放入设计人员的必修课中，因为我觉的它的重要性并不压于后台的架构设计。
     昨天晚上看了中国队和瑞士的热身赛，中国队又输的灰头土脸的，幸好董在最后时候打进一球，好歹也使得中国队摘掉了逢欧球队不破门的尴尬局面。在我看来，整场比赛，从场面看来，中国队并未处于明显的下风，和之前的England VS Jamaica一边倒的比赛不完全不同。而1：4落后的症结在于，中国球员在场上太想进球了，太急于证明自己，思想包袱非常的重，导致放不开，太僵硬，看得都累，而被寄予厚望的鲁菜并没有打出中超的水准。 反观瑞士，和现场的球迷一样，他们踢的相当轻松，相当享受。在放松的状态下，能够打出高水平。
     有的时候想想中国的环境，我们的软件产业，和中国队相似的，前进的道路非常的累，大多数人的工作只是为了生计，所以，难以创造出真正对整个中国软件行业有价值的东西。其实，大家都知道,只有在一种享受编程带来的快乐的同时才会创造出更好的软件吧。

     今天比较郁闷。今天新来不久的员工对我说，他觉的我有点自大。是的，很久以来，一些事情总是捆饶着我，使我有的时候显示出浮躁的情绪。这一点，我的确需要认真反省。但我也无法在面对一个工作时间不比短，但连写个基本的读写Property都成问题的员工面前表现得非常的绅士。我向来对自身代码的要求是比较高的，况且，领导还要我带他做事。

    很久以来，都希望能有一个拍档，不需要太多，一个就够了，在工作方面能够心有灵犀，经过简单的交流就能够明确知晓对方的意图，并且能够有不同的擅长，取长补短，相互进步。 .....可遇不可求啊。

    最近的一些工作，都是我一个人扛着，因为我希望能够做得更好。wincony进展顺利......

一个典型的Ajax应用的方式场景是

1. 从Client端发起一个请求
2. Server端响应请求并且执行业务逻辑
3. Server端执行完毕业务逻辑后，封装结果数据返回客户端
4. Client端使用Javascript技术处理返回的数据

    从上面的处理逻辑看，数据，显然在Ajax应用中占有举足轻重的地位，甚至可以说，Data-Centre是Ajax的核心。总结了Ajax应用中数据传递的几种方式

HTML
     在服务端生成HTML Snippet，返回给客户端，客户端只需要使用innerHTML方法将HTML片段直接插入到适当的位置即可。这种数据传递方式又称为AHAH(Asynchronous Html And Http)。使用这种方式的好处是在Client端实现简单，结合服务端模板技术能很好的在服务端动态生成内容，能够实现无刷新的效果。wincony 会使用这种方式来传递数据。使用AHAH方式要注意的一点是，浏览器不会执行生成的在<script>...</script>标签的脚本，使用eval方法可以解决这个方法。

Javascript
    在服务端动态生成Javascript脚本，返回给客户端，客户端使用eval语句来执行这些脚本，这些脚本可以动态渲染页面。这种方式还是比较Powerful的。它的应用场景在于能够根据配置生成定制的脚本，并且在客户端执行。典型的，不同的公司有不同的密码校验规则，但希望使用Client校验方式，这时候，在服务端生成JS，发送到客户端执行是很好的方案。

XML
   正统的Ajax数据传递格式，服务端生成XML formatted的数据，客户端拿到数据后使用DOM或者其他技术来解析XML，动态的将数据放入HTML元素中或者生成HTML元素。它的好处的标准。XML的好处并不在于数据的存贮，而在于支持它是统一的数据传递格式，有很多的技术来支撑XML的解析和生成。

    在实际应用当中，可能需要视实际情况选择其中一种或者几种结合在一起使用。 一句话，So think before using this technique

      随着软件系统越来越复杂，页面数量快速上升,如何高效率地组织这些页面，并最终拼装成完整的UI页面呈现给最终客户是值得思考的。

     我们在开发UI时,会发现
      1. 许多页面的页面结构、布局是相同的，只是显示内容不同
      2. 系统的展示风格也随着展示内容的变化而不断地发生变化
      3. 如果做为产品,则更加需要灵活的展现风格/布局方案

 

      其实页面组装也可以认为是一个布局的过程,所以,在我看来,一个系统可以划分为二类布局视图
    一类是框架级别的视图,可以使用模版控制技术来解决,比较流行的有Sitemesh,Struts tiles,还有一类是页面单元级别的,因为它的粒度比较小,所以,需要使用CSS来控制布局.

 

     一个好的UI组装方案至少有以下几点益处
     1. 尽可能做到客户端调用透明,设计不二法则.
     2. 能够拼装出结构良好的HTML代码.这点很重要,由于是由多个页面片段拼装而成,往往很难做到最后生成的页面是结构良好的.这点sitemesh做的非常好.
     3. 减少页面代码量. 一个好的UI组装方案,可以尽可能多的抽取公用部分,从而减少页面代码量,易于日后的维护.
     4. 能够灵活的响应布局的变化.

 

 

       Sitemesh是opensymphony旗下的一款页面组装框架,非常的优秀,使用Decorator模式,我使Sitemesh后,页面重复代码量大大下降,页面的组织结构也得到很大的改善。
       Struts tiles是Struts的子项目。采用类似的JSP template技术。

       在我看来Sitemesh和Tiles本质的区别在于,Sitemesh以一种被动的方式接受引擎的装饰，一旦决定了以哪种方式装饰请求页面,则对于客户端来说是被动的。而Tiles则是主动选择模板,将动态内容嵌入模版。 二者各有长处,Sitemesh的优势在于静态主页面组装 ,而Tiles的优势在于动态主页面组装。

    I am unhappy today. Someone injure my pride. I did my best to help her, but she turned a blind eye to my help and did so foolish thing. What shoud i do ? I feel tired,not for my job,but for my life.

     英格兰的坚毅，西班牙的热情，德国的果敢。红军利物浦在昨晚英超足总杯决赛上又力挽狂澜，上演球迷期待的翻盘好戏。落后二球的状况下，依靠天才球星杰拉德在补时阶段的40米重炮轰门，顽强的以3：3逼平对手，并在残酷的点球大战中，依靠西班牙门神雷纳的神勇发挥，终捧足总杯。

    在这场结果正常，过程曲折的比赛中，双方球员向全世界球迷诠释了什么是足球的精髓，技巧，团结，坚毅，荣誉感.......

    近一年看球的时间并不算太多，不过在世界杯前夕看一场如此精彩的决赛，还是觉的过瘾。红军利物浦在球迷心目中俨然成为了翻盘大师，在逆径中爆发出的能量是最可怕的。敬佩敬佩。

 

     最近一直在构思如何才能完成一个极度的注重实效的，又不失强大灵活性与动态特征的UI的开发框架。总是希望在WYSIWYH(所见即所得)和动态性之间获取二者之间的最大利益的平衡。从实质上说，Web界面的发展从一开始只具备静态特征(纯html)到赋予了一些动态特性(JSP,ASP,PHP....)，然后发展到又元数据驱动，服务端生成UI组件，在动态特征不断升级的同时，其开发阶段所见即所得的特性则近一步被削弱。
    而Taperstry的纯HTML开发方式，然后通过对html元素的decorator是一个非常好的则中方案。而JSF + Facelets的组合也让人看到JSF的一些曙光。毕竟使用纯粹的Tag导致页面完全被污染是一件得不偿失的干活。我期望能够有一个引擎可以类似以上方案，可以decorator灵活的Template方案(Velocity或者Freemaker)
    而对于一些页面排版相关的Html元素，是否应该独立抽取出来做为摸板单点维护，还是值得商榷的。留在页面中，易于开发维护时的WYSIWYH，但不易于全局的变换。而置于Template单点维护，则易于统一修改，不易于WYSIWYH。正如我之前设计的 NewFace正是走上了后者的道路，我是不是应该在下一版本中重新审视一下自己的方案呢？

下面是我倾向的实现方式
taperstry solution, 注意jwcid属性

<span jwcid = "@Insert" value = "ognl:currentHolidayBooking.holidayID">1</span>

 

JSF + Facelets solution，注意jsfc属性

<input type="text" jsfc="h:inputText" value="#{foo.bar}"/>